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Abstract 


In  the  last  three  years,  there  has  been  a  great  deal  of  turbulence  in  defense 
acquisition  policy.  This  has  led  to  confusion  within  the  acquisition  workforce  over  the 
major  policy  thrusts,  terminology,  and  unobvious  implications  of  the  changes.  The  new 
acquisition  framework  has  added  complexity,  with  more  phases  and  delineations  of 
activity  -  and  both  the  number  and  level  of  decision  reviews  have  been  increased. 
Decision  reviews  are  typically  used  as  top  management  level  control  gates,  and  are 
also  a  feature  of  centralized  control  within  a  bureaucracy.  Although  the  current  stated 
policy  is  to  foster  an  environment  supporting  flexibility  and  innovation,  the  new 
framework  will  cause  Program  Managers  to  devote  more  time  and  other  resources 
managing  the  decision  bureaucracy.  Moreover,  the  implicit  aspects  of  the  still  new 
model  have  not  been  fully  realized,  and  may  result  in  policy  that  actually  lengthens 
programs  and  delivers  yesterday’s  technology  tomorrow  --  counter  to  goals  of  rapid 
transformation.  The  framework,  and  its  associated  requirements  for  senior  level 
reviews,  are  opposed  to  the  rapid  and  evolutionary  policy  espoused,  and  are  counter  to 
appropriate  management  strategies  for  a  transformational  era. 
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Introduction 


The  issuance  of  Department  of  Defense  Directive  5000.1 1  and  Instruction 
5000. 22  on  May  12,  2003,  is  the  third  significant  revision  of  acquisition  policy  in  as  many 
years.  Looking  further  back,  these  three  revisions  of  regulatory  guidance  had  evolved 
from  two  previous  versions  in  199 13  and  19964.  Each  had  its  major  thrusts  and  tenets, 
and  perhaps  of  most  importance  to  Program  Managers,  modifications  to  the  “Defense 
Systems  Acquisition  Management  Process” 5  or  “Defense  Acquisition  Framework”6 
which  is  the  broad  paradigm  of  phases  and  milestone  reviews  in  the  life  of  an 
acquisition  program.  The  purpose  of  this  research  is  to  examine  the  evolution  of  this 
framework  and  draw  attention  to  the  explicit  and  implicit  aspects  of  recent  changes  to 
the  various  models  to  better  understand  its  current  form. 

This  latest  version  of  the  5000  series  was  actually  drafted  in  the  documents 
rescinding  its  predecessor.  According  to  his  memorandum  signed  on  October  30,  2002, 
Deputy  Secretary  of  Defense  Paul  Wolfowitz  said  the  series  required  revision  “to  create 
an  acquisition  policy  environment  that  fosters  efficiency,  flexibility,  creativity  and 
innovation.”7  Interim  guidance  was  issued,  along  with  the  rescission  of  the  series,  as  a 
temporary  replacement,  outlining  principles  and  policies  to  govern  the  operation  of  the 
new  Defense  acquisition  system.  Among  them: 

3. 1  Responsibility  for  acquisition  of  systems  shall  be  decentralized  to  the 
maximum  extent  practicable  (emphasis  mine). 


1  USD(AT&L)  Department  of  Defense  Directive  5000.1,  The  Defense  Acquisition  System,  May  12,  2003. 

2  USD(AT&L)  Department  of  Defense  Instruction  5000.2,  Operation  of  the  Defense  Acquisition  System, 
May  12,  2003. 

3  USD(A)  Department  of  Defense  Directive  5000.1,  The  Defense  Acquisition  System,  February  23,  1991 . 

4  USD(A&T)  Department  of  Defense  Directive  5000.1,  Defense  Acquisition,  March  15,  1996. 

5  Defense  Systems  Acquisition  Management  Process,  Defense  Systems  Management  College,  January 
1997. 

6  Defense  Acquisition  Framework,  Defense  Systems  Management  College,  2001. 

7  Wolfowitz,  Paul,  Memorandum  for  Director,  Washington  Headquarters  Services,  Cancellation  of  DoD 
5000  Defense  Acquisition  Policy  Documents,  October  30,  2002. 
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3.18  The  PM  shall  be  the  single  point  of  accountability  (emphasis  mine), 
for  accomplishment  of  program  objectives  for  total  life  cycle  systems 
management,  including  sustainment. 

3.27  It  shall  be  DoD  policy  to  minimize  reporting  requirements  (emphasis 
mine).  Nevertheless,  complete  and  current  program  information  is 
essential  to  the  acquisition  process.  Consistent  with  the  tables  of  required 
regulatory  and  statutory  information  appearing  in  reference,  decision 
authorities  shall  require  PMs  and  other  participants  in  the  defense 
acquisition  process  to  present  only  the  minimum  information  necessary 
(emphasis  mine),  to  understand  program  status  and  make  informed 
decisions.8 

During  the  period  between  rescission  and  re-issuance  of  the  regulatory  guidance, 
DoD  officials  said  discussions  revolved  around  changes  to  give  program  managers 
more  latitude  to  be  innovative  in  applying  concepts  like  evolutionary  acquisition,  and 
relieving  them  of  the  constraints  of  an  overly  prescriptive  policy: 

Less  prescriptive  5000-series  documents  could  also  enhance  program 
managers'  abilities  to  use  their  experience,  best  business  practices  and 
innovation  “to  structure  and  execute  a  program  in  a  manner  best  suited  to  its 
particular  circumstances. . . . 

...The  old  way  of  doing  business  ‘was  too  focused  on  process  vs. 
outcomes.’  Instead  of  telling  [program  managers]  they  have  to  satisfy  a 
requirement  in  a  certain  way,  now  we're  [saying]:  'Here's  the  requirement; 
you  know  your  program,  do  what  best  suits  the  particular  conditions  of 
your  program  but  meet  the  requirement.'  The  new  guidelines  will  put  the 
full  weight  of  OSD  policy  behind  creative  program  managers  who  in  the 
past  likely  would  be  constrained  by  the  Pentagon  bureaucracy  by  making 
them  operate  according  to  rules  that  may  not  be  necessary  to  achieve  a 
desired  outcome...9 


8  Secretary  of  Defense  Memorandum,  Defense  Acquisition,  Attachment  1 ,  The  Defense  Acquisition 
System,  October  30,  2002,  (Interim  Guidance  5000.1,  p.  6). 

9  Costa,  Keith  J.,  “5000.2  Changes  Await  Approval,”  Inside  The  Pentagon,  January  1 6,  2003. 
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Paramount  in  the  objectives  of  the  new  policy  is  improved  warfighting  capability 
from  projects  and  programs  that  are  well  managed.  A  well  managed  project  is  generally 
considered  to  be  one  that  is  optimized  for  effectiveness  in  its  planning  phases  but 
emphasizes  efficiency  in  its  implementation  phases,  that  include  commissioning,  startup 
and  close  out.”10  To  this  could  also  be  added  “...and,  in  the  eyes  of  the  customer,  is 
perceived  as  satisfactory  in  use,”  or  in  defense  terms-operational  effectiveness  and 
suitability. 

Beyond  the  business  aspects  of  program  management,  measurement  of  system 
effectiveness  and  suitability  are  the  principal  test  objectives  sought  from  full  operational 
testing  late  in  the  life  of  most  projects,  and  just  before  deployment  of  the  program’s 
products  to  the  warfighting  force.  Operational  effectiveness  and  suitability  are  the  key 
success  indicators  by  which  the  product  will  ultimately  be  judged,  if  not  against  which 
decisions  can  be  taken  during  the  project.  However,  efficiency  in  cost  and  schedule  still 
predominate  as  the  more  apparent  and  quantifiable  measures  of  project  success  prior 
to  full  operational  assessment. 

The  current  policy  makes  clear  that  it  is  the  Milestone  Decision  Authority  -  not 
the  Program  Manager  -  who  is  responsible  for  the  overall  program: 

3.4  The  Milestone  Decision  Authority  (MDA)  is  the  designated  individual 
with  overall  responsibility  fora  program  (emphasis  mine).  The  MDA  shall 
have  the  authority  to  approve  entry  of  an  acquisition  program  into  the  next 
phase  of  the  acquisition  process  and  shall  be  accountable  for  cost, 
schedule,  and  performance  reporting  to  higher  authority,  including 
Congressional  reporting. 

3.5  The  Program  Manager  (PM)  is  the  designated  individual  with 
responsibility  for  and  authority  to  accomplish  program  objectives  for 
development,  production,  and  sustainment  to  meet  the  user's  operational 
needs.  The  PM  shall  be  accountable  for  credible  cost,  schedule,  and 
performance  reporting  to  the  MDA  (emphasis  mine). 


10  Project  Management  Guidelines  (Private  BC  Corporation),  1995,  Wideman  Comparative  Glossary  of 
Project  Management  Terms  v3.1 , 2002. 
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4.3.5  Streamlined  and  Effective  Management.  Responsibility  for  the 
acquisition  of  systems  shall  be  decentralized  to  the  maximum  extent 
practicable.  The  MDA  shall  provide  a  single  individual  with  sufficient 
authority  (emphasis  mine)  to  accomplish  MDA-approved  program 
objectives  for  development,  production,  and  sustainment.  The  MDA  shall 
ensure  accountability  and  maximize  credibility  in  cost,  schedule,  and 
performance  reporting.11 

It  is  also  clear  that  together,  the  Program  Manager  and  Milestone  Decision 
Authority  share  responsibility  for  development  and  oversight  of  the  program: 

4.3.1  Flexibility.  There  is  no  one  best  way  to  structure  an  acquisition 
program  to  accomplish  the  objective  of  the  Defense  Acquisition  System. 

MDAs  and  PMs  shall  tailor  program  strategies  and  oversight,  including 
documentation  of  program  information,  acquisition  phases,  the  timing  and 
scope  of  decision  reviews,  and  decision  levels,  to  fit  the  particular 
conditions  of  that  program,  consistent  with  applicable  laws  and  regulations 
and  the  time-sensitivity  of  the  capability  need.12 

Though  the  5000  series  provides  guidance  for  all  levels,  or  Acquisition 
Categories  (ACAT),  of  programs,  its  language  is  particularly  applicable  to  the  largest, 
ACAT  I,  Major  Defense  Acquisition  Programs  (MDAP).  In  such  cases,  the  MDA  is  the 
Defense  Acquisition  Executive,  who  also  chairs  the  Defense  Acquisition  Board  (DAB)  as 
a  decision  making  body  for  program  milestone  reviews.  And  while  the  wording  above 
might  indicate  that  the  MDA  and  PM  jointly  plan  or  collaborate  in  some  way  on  program 
strategy,  there  are  in  fact  both  a  Component  Acquisition  Executive  and  Program 
Executive  Officer  in  the  hierarchy  between  them,  and  direct  communication  between 
MDA  and  PM  is  infrequent.  Other  top  management  stakeholders  are  OSD  staff 
principals  who  sit  in  membership  on  the  Defense  Acquisition  Board,  where  milestone 
decision  reviews  are  conducted.  Communication  between  PM  and  OSD  staff  principals 
is  more  frequent,  especially  via  the  Overarching  Integrated  Product  Team  process.13 


11  USD(AT&L)  Department  of  Defense  Directive  5000.1,  The  Defense  Acquisition  System,  May  12,  2003. 

12  Ibid. 

13  Office  of  the  Under  Secretary  of  Defense  (Acquisition  and  Technology)  Washington,  DC  20301-3000 
DoD  Integrated  Product  and  Process  Development  Handbook,  August  1998. 
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The  very  latest  DoD  5000  policy  changes  have  come  during  a  time  of  DoD 
Transformation,  which,  while  larger  in  scope  than  solely  equipment  and  technology,  is 
chiefly  focused  on  changes  to  force  structure  and  weapons  employment  capabilities. 
The  DoD  uses  three  Decision  Support  Systems  to  manage  weapons  modernization  via 
requirements  generation,  resource  allocation  and  acquisition  of  systems  (The  Joint 
Capabilities  Integration  and  Development  System,  Planning,  Programming  Budgeting 
and  Execution  process,  and  the  Defense  Acquisition  System,  respectively).  Change,  to 
a  greater  and  lesser  degree,  is  occurring  in  all  three  systems  to  facilitate  the 
transformational  era.  These  process  changes  require  re-education  and  adaptation  by 
all  involved  in  them  for  proper  implementation,  and  are  in  all  cases  significant.  This 
study  considers  only  changes  to  the  Defense  Acquisition  System  framework  and  its  use 
as  a  decision  making  tool. 
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The  Challenges  of  Defense  Program  Management 


Defense  systems  in  particular,  known  for  their  size  and  technological  pursuits, 
are  seen  as  among  the  most  challenging  of  projects.  Gadeken,  building  upon  previous 
studies  at  the  Defense  Systems  Management  College,  et  al. ,  concluded  that  the  Project 
Manager  competency  of  systematic  and  innovative  thinking  were  among  the  most 
needed  and  critical  in  order  to  accommodate  growing  complexities.14 

Program  Managers  and  policy  makers  have  long  realized  that  of  these  three 
Decision  Support  Systems  available  to  the  DoD,  two  of  them  are  fittingly  event-based, 
but  one  (PPBE)  is  calendar-driven  by  congressional  authorization  and  appropriation. 
While  any  project  requires  the  accurate  estimation  of  costs  and  time  to  execute,  the 
annual  cycle  of  PPBE  necessitates  the  total  forecasting  of  annually  incremented 
program  resources  for  the  near  and  far  term,  and  across  multiple  “colors  of  money.”  It 
is  this  same  system  that  has  long  been  blamed  for  instability  in  DoD  programs,  as  high 
level  adjustments  are  made  each  year  that  trickle  down  to  programs  in  the  form  of 
decrements.15 

Inherent  difficulty  in  the  management  of  any  program  is  exacerbated  for  the  DoD 
by  several  additional  factors,  which  have  become  even  more  apparent  in  the  last  twenty 
years.  Large  defense  systems  are  very  complex  systems,  consisting  of  hardware  and 
software,  multiple  suppliers,  etc.  and  requiring  design  approaches  that  can  alleviate 
complexity  via  decomposition  into  simpler  subsets,  etc.  Rapid  technology  changes, 
yielding  obsolescence,  have  become  particularly  problematic  for  very  large  systems 
with  acquisition  life  cycles  spanning  a  long  period  of  time.  Thus,  it  may  not  even  be 


14  Gadeken,  Owen  C.,  “Project  Managers  as  Leaders  -  Competencies  of  Top  Performers,”  RD&A, 
January  -  February  1 997. 

15  Johnson,  Stuart,  Libicki,  Martin  C.  and  Treverton,  Gregory  F.,  New  Challenges  New  Tools  for  Defense 
Decisionmaking,  Rand,  2003. 
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feasible  to  fully  define  the  operational  capabilities  and  functional  characteristics  of  the 
entire  system  before  commencing  advanced  development.16 

A  series  of  influential  GAO  reports  on  defense  acquisition  from  1996  through 
2002  concluded  that  the  DoD  had  repeatedly  spent  more  time  and  money  than  originally 
planned  on  weapon  systems,  and  urged  that  the  Department: 

■  Carefully  assess  technology17  and  separate  its  development  from  product 
(advanced)  development  (i.e.  mature  the  candidate  technologies  before 
commitment  to  advanced  development)18 

■  Move  to  a  “knowledge-based”  approach,  to  learn  more  about  a  design’s 
capability  to  satisfy  requirements  and  a  prototype’s  ability  to  be  manufactured, 
earlier  in  the  process.19 

■  Change  the  environment  to  allow  PMs  to  identify  unknowns  as  high  risks  without 
suffering  criticism  and  loss  of  support.20 

The  DoD  5000  series  acknowledges  these  many  complexities  and  difficulties 
facing  MDAs  and  PMs  in  their  management  and  oversight  of  large  weapon  system 
developments.  An  approach  to  mitigate  these  technological  challenges,  especially  in 
the  post-2000  series,  is  evolutionary  acquisition,  referred  to  by  some  outside  of  DoD  as 
progressive  acquisition.  Also  advocated  by  the  General  Accounting  Office,  it  has 
evolved  worldwide  as  a  concept  over  the  past  two  decades.  It  is  an  incremental 
development  approach,  using  iterative  development  cycles  versus  a  single  grand 
design.  Described  succinctly  by  the  Western  European  Armaments  Group,  the 
progressive  acquisition  approach  is: 


16  Pitette,  Giles,  “Progressive  Acquisition  and  the  RUP:  Comparing  and  Combining  Iterative  Process  for 
Acquisition  and  Software  Development,”  The  Rational  Edge,  November  2001. 

17  GAO,  “Joint  Strike  Fighter  Acquisition  -  Mature  Technologies  Needed  to  Reduce  Risks,”  02-39, 
October  2001 . 

18  GAO,  “Better  Management  of  Technology  Development  Can  Improve  Weapon  System  Outcomes,” 
NSIAD-99-1 62,  July  1999. 

19  GAO,  “Best  Practices  -  Capturing  Design  and  Manufacturing  Knowledge  Early  Improves  Acquisition 
Outcomes,”  02-701,  July  2002. 
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a  strategy  to  acquire  a  large  and  complex  system,  which  is  expected  to 
change  over  its  lifecycle.  The  final  system  is  obtained  by  upgrades  of 
system  capability  through  a  series  of  operational  increments.  (It)  aims  to 
minimize  many  of  the  risks  associated  with  the  length  and  size  of  the 
development,  as  well  as  requirements  volatility  and  evolution  of 
technology.21 

Pittete  explains  further: 

An  essential  goal  of  (progressive  acquisition)  is  the  rapid  fielding  of  a 
usable  system  that  not  only  addresses  an  initial  and  validated  statement  of 
needs,  but  also  anticipates  iterative  upgrades  of  system  capability  as 
development  progresses  through  a  series  of  increments.  Each  successive 
increment  yields  an  operational  version  of  the  system  that  meets  a  pre¬ 
specified  subset  of  the  overall  system  requirements. 

Continuous  user  feedback  based  on  previously  fielded  increments  is  an 
essential  element  of  the  approach.  It  may  significantly  influence  the 
definition  and  development  of  later  increments.  In  the  same  way, 
technology  updates  may  be  accommodated  across  increments,  reflecting 
the  evolution  or  obsolescence  of  hardware  and  software  items,  including 
commercial  off-the-shelf  products. 

This  approach  continues  until  the  final  system  configuration  is  achieved.22 

Very  similar  in  description,  DoD’s  adaptation  of  this  approach  as  “evolutionary 
acquisition”  is  a  major  policy  thrust  in  the  series,  and  is  the  stated  “preferred  approach” 
toward  all  new  system  developments.  It  is  described  most  fully  in  DoDI  5000.2: 

3.3  Evolutionary  Acquisition  is  the  preferred  DoD  strategy  for  rapid 
acquisition  of  mature  technology  for  the  user.  An  evolutionary  approach 
delivers  capability  in  increments,  recognizing,  up  front,  the  need  for  future 
capability  improvements.  The  objective  is  to  balance  needs  and  available 
capability  with  resources,  and  to  put  capability  into  the  hands  of  the  user 
quickly.  The  success  of  the  strategy  depends  on  consistent  and 


20  GAO,  “Successful  Application  to  Weapon  Acquisitions  Requires  Changes  in  DoD’s  Environment,” 
NSIAD-98-56,  February  1998. 

21  Western  European  Armaments  Group  WEAG  TA-13  Acquisition  Programme,  Guidance  on  the  Use  of 
Progressive  Acquisition,  Version  2,  November  2000. 

22  Pitette,  Giles,  “Progressive  Acquisition  and  the  RUP:  Comparing  and  Combining  Iterative  Process  for 
Acquisition  and  Software  Development,”  The  Rational  Edge,  November  2001. 
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continuous  definition  of  requirements,  and  the  maturation  of  technologies 
that  lead  to  disciplined  development  and  production  of  systems  that 
provide  increasing  capability  towards  a  materiel  concept.23 

This  particular  policy  thrust  is  important  to  this  study  as  it  pertains  to  the 
framework  of  phases  and  decision  reviews  of  a  program  moving  toward  completion.  It 
is  meant  to  change  the  way  programs  are  structured  and  products  delivered.  -  actually 
separating  projects  into  smaller,  less  complex  increments.  It  is,  additionally,  one  of 
several  aspects  of  the  new  policy  that  affect  the  framework  and  its  use  as  a 
management  control  mechanism. 


23  USD(AT&L)  Department  of  Defense  Instruction  5000.2,  Operation  of  the  Defense  Acquisition  System, 
May  12,  2003. 
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Organizational  Control  Theory  and  Defense 
Acquisition 


Sylvester  and  Ferrara  provided  an  insightful  view  of  the  organizational  struggle 
within  OSD  to  adopt  the  evolutionary  acquisition  policy.24  Evolutionary  acquisition  can 
even  be  viewed  as  analogous  to  these  authors’  iterative  approach  to  policy 
implementation  via  “muddling  through”  -  (i.e.  successive  limited  comparisons)  versus 
using  a  more  comprehensive  “grand  design”  approach.25  Perhaps  most  impressive  in 
this  paper  is  the  intra-organizational  complexities  and  diverse  interests  that  are 
revealed,  and  in  the  authors’  assertions  that  policy  ambiguity  and  organizational  conflict 
are  not  necessarily  counterproductive.  They  further  describe  in  some  detail  the 
distribution  of  power  affecting  weapon  system  acquisitions  among  stakeholders  outside 
of  DoD  (i.e.  Congress  and  the  defense  industry)  as  well  as  within  (i.e.  Joint 
Requirements  Oversight  Council  (JROC),  and  Director  of  Operational  Test  &  Evaluation 
DOT&E),  Comptroller,  etc.).  Vital  to  the  interests  of  many  is  the  need  for  bureaucratic 
control  over  the  acquisition  process.  As  others  have  observed  through  recent  decades, 
each  of  these  powerful  stakeholders  perceives  and  “exercises  an  oversight 
responsibility  to  ensure  that  laws  and  regulations  are  observed  and  programs  pursued 
efficiently.”26 

Wideman  also  advocated  progressive  (evolutionary)  acquisition,  and  recognized 
senior  management  responsibility  for  financial  accountability  in  private  and  public 
projects  and  their  preference  for  central  control.  He  noted  three  problems  with  senior 
management  control  over  complex  developments  such  as  software  enterprises  like 


24  Sylvester,  Richard  K.  and  Ferrara,  Joseph  A.,  Conflict  And  Ambiguity  Implementing  Evolutionary 
Acquisition,  Acquisition  Review  Quarterly  -  Winter  2003. 

25  Lindblom,  C.  E.  (1959).  The  Science  of  Muddling  Through,  Public  Administration  Review,  19  (Spring), 
(Reprinted  in  Perspectives  on  Public  Bureaucracy  (2nd  ed.),  pp.  132-150,  by  F.  A.  Kramer  (Ed.),  1977, 
Cambridge,  Massachusetts:  Winthrop  Publishers). 

26  Fox,  J.  Ronald,  The  Defense  Management  Challenge:  Weapons  Acquisition,  Harvard  Business  School 
Press,  1988. 
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Defense  Information  Systems,  even  when  projects  were  not  particularly  large  or  lengthy. 
He  suggested  that  the  acquiring  authority  or  sponsor: 


■  Has  difficulty  staying  abreast  of  ongoing  developmental  efforts 

■  Is  not  technically  prepared  for  the  dynamics  of  project  changes 

■  Has  too  large  a  span  of  control  to  effectively  manage  locally 

Thus,  he  suggests  that,  as  a  minimum,  better  means  of  communicating  are 
required  to  serve  both  the  needs  of  developer  and  sponsor.27 

The  above  observations  in  large,  complex  programs  align  with  classic 
contingency  theory,  which  holds  that  organizational  structures  must  change  in  response 
to  contingencies  of  size,  technology,  and  as  external  environments  become  more 
complex  and  dynamic.  Indeed,  it  has  long  been  accepted  that  when  faced  with 
uncertainty  (a  situation  with  less  information  than  is  needed)  the  management  response 
must  either  be  to  redesign  the  organization  for  the  task  at  hand,  or  improve 
communication  flows  and  processing.28  Van  Creveld  applies  this  same  principle  to 
command  and  control  of  combat  elements  in  war,  stating  that  the  command  structure 
must  either  create  a  greater  demand  for  information  (vertically,  horizontally,  or  both)  and 
increase  the  size  and  complexity  of  the  directing  organ,  or  enable  the  local  forces  to 
deal  with  the  situation  semi-independently.  His  central  theme  is  that  decentralized 
control  is  the  superior  method  of  dealing  with  uncertainty,  whether  with  the  task  at  hand 
or  with  transformation  of  the  organization  itself.29 

Research  by  Van  de  Ven  and  Delbecq  has  further  shown  that  as  complexity  and 
uncertainty  increase,  hierarchical  management  control  strategies  are  less  favored  than 
adaptation  to  less  formal  and  horizontal  communication  channels,  and  the  effectiveness 


27  Wideman,  R.  Max,  Progressive  Acquisition  and  the  RUP  Part  I:  Defining  the  Problem  and  Common 
Terminology,  The  Rational  Edge,  2002. 

28  Galbraith,  J.  R.,  1973,  Designing  Complex  Organization,  Reading,  Massachusetts:  Addison-Wesley. 

29  Van  Creveld,  Martin,  Command  in  War,  Harvard  University  Press,  1985. 
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of  formal  controls  becomes  less  effective.30  To  continue  discussion  of  management 
control  as  it  might  relate  to  defense  acquisition,  we  should  perhaps  next  consider 
organizations  and  their  environments  in  very  broad  terms. 

Gareth  Morgan  traced  organizational  theory  through  the  past  century  and  depicts 
organizations  as  a  variety  of  images,  or  metaphors  in  his  treatise,  Images  of 
Organization.  He  claims  these  “images”  of  organizations  are  actually  metaphors,  much 
like  our  graphic  depictions  of  projects,  and  uses  the  machine,  the  organism,  the  brain, 
and  others  to  illustrate  approaches  to  organization.  He  describes  many  large  and 
complex  organizations  structured  as  machine  bureaucracies,  with  routinized  processes 
of  administration  the  way  a  machine  routinizes  production.  He  discusses  at  length  how 
well  the  machine  bureaucracy  fit  Western  society  organizations  in  the  period  of 
industrialization,  particularly  under  conditions  of  straightforward  tasks,  a  predictable  and 
stable  environment,  and  where  precision,  efficiency  and  compliance  were  desired.  He 
also  notes  today’s  transition  from  industrial  age  to  information  age,  with  its 
accompanying  implications  of  rapid  change  and  turbulence.  He  warns  that  large 
hierarchical,  mechanistic  organizational  forms  have  difficulty  adapting  to  change  and 
are  not  designed  for  innovation: 

The  machine  bureaucracy  and  the  divisionalized  form  tend  to  be 
ineffective  except  under  conditions  where  tasks  and  environment  are 
simple  and  stable.  Their  highly  centralized  systems  of  control  tend  to 
make  them  slow  and  ineffective  in  dealing  with  changing  circumstances. 

While  appropriate  for  firms  that  are  production  driven,  they  are  often 
inappropriate  for  firms  that  are  market  or  environment  driven.31 

Another  classical  concept  of  organizational  theory  is  Ashby’s  Law  of  Requisite 
Variety,  which  states  that  the  internal  regulatory  mechanisms  of  a  system  must  be  as 
diverse  as  its  environment  in  order  to  cope  with  the  variety  of  challenges  imposed  by  it. 
Moreover,  organizational  evolution  and  survival  are  dependent  upon  it,  and  capacities 


30  Delbecq,  Andre  L.,  Van  de  Ven,  Andrew  and  Gustafson,  David,  Group  Techniques  for  Program 
Planning,  2nd  edition,  Greenbriar  Press,  Madison,  Wisconsin,  1986. 

31  Morgan,  Gareth,  1997,  Images  of  Organization,  Sage  Publications. 
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are  enhanced  when  variety  is  built  at  the  point  of  interaction  with  the  environment.32 
This  too  suggests  that  the  organization’s  structure  and  control  strategy  must  be 
matched  to  its  environment  to  enhance  performance,  and  that  open  and  flexible  styles 
and  processes  of  management  are  required  for  dynamic  market  and  technological 
conditions.  Further  research  by  Burrell  and  Morgan  indicate  that  any  incongruence 
among  management  processes  and  the  organization’s  environment  tend  to  reduce 
organizational  effectiveness.33 

In  their  book,  The  Intelligent  Organization,  Gifford  &  Elizabeth  Pinchot  make  an 
even  stronger  case  for  decentralized  management  in  large  complex  organizations  faced 
with  transformational  change.  They  suggest  that  as  organizations  today  face  increasing 
complexity,  rapidity  of  change,  distributed  information,  and  new  forms  of  competition, 
organizations  must  grow  more  intelligent  to  confront  and  defeat  the  diverse  and 
simultaneous  challenges.  They  posit  that  for  an  organization  to  be  fully  intelligent,  it 
must  use  the  intelligence  of  its  members  all  the  way  down  the  hierarchy.  They  note  that 
with  distributed  information  there  is  distributed  intelligence,  and  failure  to  render 
authority  to  those  closest  to  the  problem  will  yield  lethargy,  mediocre  performance,  or 
worse  -  paralysis.  Control  will  be  maintained,  and  anarchy  will  not  occur  -  but  neither 
will  success.34 

What  the  cumulative  research  appears  to  support  is  that,  for  large  complex 
hierarchies  such  as  the  Department  of  Defense,  decentralized  control  and 
empowerment  should  be  an  organizational  strength,  given  today’s  environment  of 
program  complexity,  evolving  requirements,  and  rapidly  changing  technology. 


32  Ashby,  W.  R.,  An  Introduction  to  Cybernetics,  London:  Chapman  &  Hall,  1960. 

33  Morgan,  Gareth,  1997,  Images  of  Organization,  Sage  Publications. 

34  Pinchot,  Gifford  and  Elizabeth,  The  End  of  Bureaucracy  and  the  Rise  of  the  Intelligent  Organization. 
Berrett-Koehler  Publishers,  San  Francisco,  1993. 
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An  Examination  of  Project  Management  Life  Cycle 
Models 


Models  have  long  been  used  to  illustrate  the  integration  of  functional  efforts 
across  the  timeline  of  a  project  or  program.  It  is  the  successful  integration  of  these 
diverse  elements  that  is  the  very  essence  of  project  management.  Models  also  help  us 
to  visualize  the  total  scope  of  a  project  and  “see”  its  division  into  phases  and  decision 
points.  The  interaction  and  overlapping  of  many  and  varied  activities  such  as  planning, 
engineering,  test  and  evaluation,  logistics,  manufacturing,  etc.  must  be  adroitly 
managed  for  optimum  attainment  of  project  cost,  schedule  and  technical  performance 
outcomes. 

Project  Management  Institute 

The  Project  Management  Institute’s  Project  Management  Body  of  Knowledge 
(PMBOK®)  provides  generally  accepted  knowledge  and  practices  in  the  broad  field  of 
project  management.35  Striving  for  commonality  across  diverse  business  areas  and 
product  commodities,  it  provides  a  generic  framework  as  a  structure  for  understanding 
the  management  of  a  project  or  program.  In  the  figure  below  (Fig.  1 .),  a  project  life 
cycle  is  depicted  as  costs  and  staffing  relative  to  time. 


35  Project  Management  Institute,  A  Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK® 
Guide),  2000  Edition,  Pennsylvania,  2000. 
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Fig.  1.  Sample  Generic  Project  Life  Cycle,  Adapted  from  PMBOK®  2000 

Project  Management  difficulty  climbs  along  the  scale  of  system  complexity  and 
technological  uncertainty,  and  is  simplified  by  division  of  the  effort  into  phases,  with 
points  between  for  management  review  and  decision. 

Because  projects  are  unique  undertakings,  they  involve  a  degree  of 
uncertainty.  Organizations  performing  projects  will  usually  divide  each 
project  into  several  project  phases  to  provide  better  management  control 
and  appropriate  links  to  the  ongoing  operations  of  the  performing 
organization.  Collectively,  the  project  phases  are  known  as  the  project  life 
cycle.... 

...Each  project  phase  normally  includes  a  set  of  defined  work  products 
designed  to  establish  the  desired  level  of  management  control  (emphasis 
mine). 

The  conclusion  of  a  project  phase  is  generally  marked  by  a  review  of  both 
key  deliverables  and  project  performance  in  order  to  (a)  determine  if  the 
project  should  continue  into  its  next  phase  and  (b)  detect  and  correct 
errors  cost  effectively.  These  phase-end  reviews  are  often  called  phase 
exits,  stage  gates,  or  kill  points.36 

The  institute  acknowledges  a  variety  of  approaches  to  modeling  project  life 
cycles,  with  some  so  detailed  that  they  actually  become  management  methodologies. 


36  Project  Management  Institute,  A  Guide  to  the  Project  Management  Body  of  Knowledge  (PMBOK® 
Guide),  2000  Edition,  Pennsylvania,  2000. 
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Illustration  of  generic  project  management  processes  or  activities  across  time  are 
depicted  thus  (Fig. 2.): 


Fig.  2.  Project  Management  Processes,  Adapted  from  PMBOK®  200037 

Of  particular  note  in  this  model  is  the  delineation  of  distinct  yet  overlapping 
processes,  across  a  project  or  within  phases,  to  initiate,  plan,  execute,  control,  and 
eventually  close  the  phase  or  project.  The  PMBOK®  provides  examples  of  how  various 
industry  business  areas  model  their  “acquisition”  process.  A  glimpse  into  the  project 
models  of  other  types  of  enterprises  may  serve  for  edification  and  to  provide  some  other 
perspectives  for  viewing  the  continually  evolving  Department  of  Defense  model. 


Construction  Projects 

In  the  construction  industry  (Fig.  3.)  a  project  is  represented  by  four  main  phases 
(stages): 


37 


Ibid. 
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Fig.  3.  Representative  Construction  Project  Life  Cycle,  Adapted  from  PMBOK®  200038 

Feasibility  Stage  -  In  this  first  phase,  projects  are  formulated,  feasibility  studies 
are  conducted,  and  an  overall  project  strategy  is  designed  and  approved  by  a  sponsor. 
Then,  a  go/no-go  decision  is  made  at  the  end  of  this  phase  to  proceed. 

Planning  and  Design  Stage  -  The  base  (preliminary)  design  is  completed,  cost 
and  schedule  are  fully  estimated,  contract  terms  and  conditions  are  defined,  and  further 
detailed  planning  is  conducted.  Major  contracts  are  awarded  to  performing 
organizations  at  the  end  of  this  phase. 

Production  Stage  -  The  manufacturing,  delivery,  civil  works,  installation,  and 
testing  are  conducted  such  that  the  facility  is  substantially  complete  at  the  end  of  this 
phase. 


38 


Ibid. 
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Turnover  and  Start-up  Stage  -  Final  testing  and  maintenance  occur  in  this  phase. 
The  facility  becomes  fully  operational  at  the  end  of  this  phase. 

Civil  construction  is  typically  viewed  as  being  on  the  relatively  low  side  of  risk  and 
complexity,  though  several  building  or  highway  projects  have  become  highly  profiled 
when  large  overruns  have  occurred.  The  Denver  Airport  and  Boston  Central 
Artery/Tunnel  projects  prove  that  underestimates  of  project  difficulty  are  not  peculiar  to 
the  Department  of  Defense.  In  fact,  a  study  of  almost  600  projects  across  twenty-five 
public  and  private  business  areas  revealed  that  DoD  weapon  system  project  cost 
growth  variances  ranked  in  the  lower  half  of  the  population  sample.39  Note  that  in  this 
model,  the  planned  work  effort  is  actually  quantified  on  the  vertical  axis  of  the  model, 
similar  to  what  would  be  found  on  an  earned  value  management  diagram  as  budgeted 
cost  of  work  scheduled. 

Pharmaceutical  Projects 

The  Food  and  Drug  Administration  model  is  shown  below  to  represent  projects 
within  the  pharmaceutical  industry.  Pharmaceutical  endeavor  is  actually  believed  by 
some  to  be  more  analogous  to  the  DoD  acquisition  enterprise  -  with  its  orientation  upon 
emerging  technology  for  new  treatment  options,  graduated  levels  of  testing,  and  strict 
regulatory  requirements  for  approval.  Human  lives  may  actually  be  at  stake  as  well. 

The  magnitude  of  effort  in  terms  of  costs  and  time  is  similar  to  many  DoD  projects,  with 
average  time  from  applied  research  to  market  being  about  ten  years  and  an  average 
investment  of  $897  million  per  new  investigational  drug.40 

The  framework  (Fig.  4.)  also  employs  a  highly  controlled  testing  and  approval 
process  for  prove-out  of  safety  and  efficacy  (similar  to  DoD’s  operational  suitability  and 
effectiveness.)  In  both  processes,  government  funded  research  contributes  to 
advancement  of  the  science  through  basic  research.  However,  unlike  today’s  weapon 


39  Blery,  F.,  Cost  Growth  and  the  Use  of  Competitive  Acquisition  Strategies,  Journal  of  the  National 
Estimating  Society,  Vol.  6,  No.  3,  Fall  1985. 

40  Ezzell,  Carol,  The  Price  of  Pills,  Scientific  American,  July  2003. 
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system  acquisition,  it  is  primarily  market  forces  that  drive  pharmaceutical  industry 
investments  and  progress  through  applied  research  and  advanced  development. 
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Fig.  4.  Representative  Pharmaceutical  Project  Life  Cycle,  Adapted  from  PMBOK®  2000 


Discovery  and  Screening  Phase  -  This  phase  includes  basic  and  applied 
research  to  identify  candidates  for  preclinical  testing.  Market  needs  are  also  compared 
to  emerging  technology. 


Preclinical  Development  -  Laboratory  and  animal  testing  is  conducted  to 
determine  safety  and  efficacy  of  the  new  drug,  as  well  as  preparation  and  filing  of  an 
Investigational  New  Drug  (IND)  application. 


Reqistration(s)  Workup  -  This  phase  includes  Clinical  Phase  I,  II,  and  III  tests 
with  increasing  numbers  of  human  subjects  in  each  sub-phase.  Preparation  and  filing  of 
a  New  Drug  Application  (NDA)  completes  the  phase. 


Postsubmission  Activity  -  During  this  period  additional  work  is  conducted  as 
required  to  support  Food  and  Drug  Administration  review  of  the  NDA  to  obtain  approval. 
Time  in  this  phase  alone  has  averaged  20  months  in  the  past  decade.41 


41  US  Food  and  Drug  Administration  Center  for  Drug  Evaluation  and  Research. 
http://www.fda.gov/cder/rdmt/default.htm,  Approval  Times  for  Priority  and  Standard  NMEs  -  Calendar 
Years  1993-2002,  (Updated  through  12/31/2002,  Posted  1/14/2003). 
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Post  marketing  studies  (additional  clinical  research)  can  also  be  an  extensive 
effort  after  FDA  approval  (similar  to  Operations  and  Support  Phase  in  DoD).  Recent 
FDA  process  reforms  have  led  to  fast-tracking  initiatives  and  other  rapid  approval 
programs  for  priority  medical  needs,  all  in  an  effort  to  reduce  the  total  cycle  time  of  a 
new  drug  endeavor. 

Software  Projects 

The  software  industry,  which  long  used  a  linear  “waterfall”  model  of  development, 
later  adopted  a  multiple-iteration  paradigm  of  cyclical  developments.  Muench,  et  al. 
describe  a  spiral  model  for  software  development  with  four  cycles  and  four  quadrants 
(Fig  5.): 


Fig.  5.  Representative  Software  Development  Life  Cycle,  Adapted  from  PMBOK®  2000 
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Proof-of-concept  cycle  -  to  capture  business  requirements,  define  goals  for 
proof-of-concept,  produce  conceptual  system  design,  design  and  construct  the  proof-of- 
concept,  produce  acceptance  test  plans,  conduct  risk  analysis  and  make 
recommendations. 

First  build  cycle  -  derive  system  requirements,  define  goals  for  first  build,  produce 
logical  system  design,  design  and  construct  the  first  build,  produce  system  test  plans, 
evaluate  the  first  build,  and  make  recommendations. 

Second  build  cycle  -  derive  subsystem  requirements,  define  goals  for  second 
build,  produce  physical  design,  construct  the  second  build,  produce  system  test  plans, 
evaluate  the  second  build  and  make  recommendations. 

Final  cycle  -  complete  unit  requirements,  final  design,  construct  final  build, 
perform  unit,  subsystem,  system,  and  acceptance  tests.42 

Wideman  states  that,  though  the  graphical  representation  of  this  spiral 
development  does  not  clearly  convey  the  process,  it  does  convey  progress  throughout 
the  project  life  span.  And  good  features  of  this  framework  are  the  constant  interplay 
with  the  end  user,  and  the  enabling  of  requirements  discovery  as  initial  work 
progresses.  Note  that  in  this  model,  full  realization  of  requirements  does  not  occur  until 
the  final  build  cycle.  The  process  continues  until  the  user  is  satisfied  or  until  resources 
are  exhausted.  Cautions  are  for  the  need  for  discipline  at  the  lowest  levels  to  remain 
cost  and  scope  conscious,  lest  cycles  be  added  indefinitely.43 

Software  has  always  been  unique  in  that  there  are  no  manufacturing  costs  per 
se.  This  affords  faster  time  periods  between  iterations  of  development  and  testing  and 
at  less  cost  than  hardware  tool-up,  component  procurement,  fabrication  and  assembly, 
etc.  The  spiral  software  model  helped  developers  to  recognize  that  end  users  do  not 


42  Muench,  Dean,  The  Sybase  Development  Framework,  Sybase,  CA,  1994. 

43  Wideman,  R.  Max,  Software  Development  and  Linearity  Part  1,  ICFAI  PRESS,  Projects  &  Profits, 
Vancouver,  BC,  Canada,  March  2003. 
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always  fully  know  their  requirements  until  they  see  the  product  in  use  -  something 
systems  engineers  have  known  for  a  long  time. 


Systems  Engineering  Within  Development  Projects 

Defined  by  the  International  Council  on  Systems  Engineering  (INCOSE): 

Systems  Engineering  is  an  interdisciplinary  approach  and  means  to 
enable  the  realization  of  successful  systems.  It  focuses  on  defining 
customer  needs  and  required  functionality  early  in  the  development  cycle, 
documenting  requirements,  then  proceeding  with  design  synthesis  and 
system  validation  while  considering  the  complete  problem.  Systems 
Engineering  integrates  all  the  disciplines  and  specialty  groups  into  a  team 
effort  forming  a  structured  development  process  that  proceeds  from 
concept  to  production  to  operation.  Systems  Engineering  considers  both 
the  business  and  the  technical  needs  of  all  customers  with  the  goal  of 
providing  a  quality  product  that  meets  the  user  needs.44 

After  years  in  the  defense  and  aerospace  industry,  authors  Forsberg  and  Mooz 
saw  developmental  project  management  in  a  systems  engineering  sense,  as  a  V-model, 
decomposing  complexity  and  flowing  down  requirements  on  the  left  side,  then 
integrating  technologies  and  verifying  attainment  of  customer  requirements  on  the  right 
side  (Fig  6.). 


44  International  Council  on  Systems  Engineering,  http://www.incose.org/whatis.html,  June  1999. 
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Fig.  6.  The  “Vee”  Model,  Adapted  from  Visualizing  Project  Management45 

Key  in  this  paradigm  or  framework  is  the  relationship  between  sides  of  the  “Vee,” 
particularly  with  regard  to  requirements  “traceability,”  for  functional  and  physical  linkage 
and  accountability  throughout  development.  While  most  applicable  to  actual  product  or 
advanced  development,  the  model  does  allow  for  concurrent  activities  to  exploit  the 
potential  for  schedule  efficiency  as  well  as  development  iterations  for  requirements 
definition  and  user  feedback. 


Projects  seem  to  be  better  visualized  with  graphic  representations  or  models. 
They  help  us  reduce  complexity  and  thereby  understand  it.  They  can  be  used,  as  we 
will  see  in  the  next  group  of  models,  to  reduce  investment  risk  via  investment  “exit 
points”  (Mooz  calls  “control  gates”)  and  to  prevent  progression  beyond  the  appropriate 
stage.  They  help  us  to  delineate  and  allocate  our  diverse  project  management  efforts. 
There  are  similarities  and  differences  between  business  areas,  with  potential  for  idea 
sharing.  In  fact,  we  have  shared  much  from  the  spiral  software  model  in  order  to 
embrace  evolutionary  acquisition  as  a  preferred  acquisition  strategy  for  weapon 
systems. 


45  Forsberg,  Kevin,  Mooz,  M.  and  Cotterham,  H.,  Visualizing  Project  Management,  2nd  Edition,  Wiley, 
2000. 
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With  some  context  provided  by  these  previous  models  we  can  now  briefly 
examine  the  evolution  of  the  DoD  5000  series  framework  with  six  versions  of  the  project 
life  cycle  management  model  used  by  DoD  over  the  last  sixteen  years. 
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An  Examination  of  the  Evolving  Defense  Acquisition 
Framework 


Models  of  program  structure  are  important  to  the  Department  of  Defense  in 
conveying  the  overall  acquisition  strategy.  According  to  the  Acquisition  Strategy  Guide, 
the  structure  and  schedule  portion  of  the  acquisition  strategy  defines: 

...the  relationship  among  acquisition  phases,  decision  milestones, 
solicitations,  contract  awards,  system  engineering  design  reviews, 
contract  deliveries,  T&E  periods,  production  releases,  and  operational 
deployment  objectives.  It  must  describe  the  phase  transitions  and  the 
degree  of  concurrency  entailed.  It  is  a  visual  overview  and  picture 
presentation  of  the  acquisition  strategy...  depicted  on  an  event-driven  time 
line  diagram...46 

Looking  back  sixteen  years  there  have  actually  been  two  “families”  of  defense 
acquisition  life  cycle  models  or  frameworks:  Pre-2000-era  and  Post-2000-era.  The  first 
of  the  Pre-2000-era  models  to  consider  here  is  the  Life  Cycle  Systems  Management 
Model  used  from  1987  until  1991  (Fig.  7.). 


46  Defense  Systems  Management  College  Press,  Acquisition  Strategy  Guide  (4th  Edition),  December 
1999. 
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The  1987  Model 
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Fig.  7.  Life  Cycle  Systems  Management  Model 

This  Life  Cycle  Systems  Management  Model  consisted  of  six  phases  of  pre¬ 
acquisition  and  acquisition  activity,  five  key  decision  points,  and  an  additional  decision 
review  optional  for  major  modifications  to  a  fielded  system.47  It  is  important  to  note  that 
not  all  systems  underwent  the  decision  reviews  described  below: 

Milestone  0  Decision  -  Approval  of  mission  need  and  program  initiation,  authority 
to  budget  for  a  new  program 

Phase  0  -  Concept  Exploration  &  Definition  Phase  -  development  of  an 
acquisition  strategy,  concepts  to  be  carried  further  into  the  next  phase  for  development, 
rationale  for  elimination  of  other  concepts,  cost,  schedule  and  operational  goals  and 
thresholds  established. 

Milestone  I  Decision  -  Approval  to  proceed  to  DemonstrationA/alidation  Phase  - 
key  areas  of  technical  risk  identified  with  plans  to  reduce  them  before  Milestone  II. 


47  Department  of  Defense  Directive  5000.1,  Major  and  Non-Major  Defense  Acquisition  Programs, 
September  1,  1987. 
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Phase  I  -  Concept  Demonstration/Validation  Phase  -  preliminary  designs 
evaluated,  experimentation,  life  cycle  cost  estimates,  formalization  of  requirements, 
trade-off  analyses,  validation  of  concept  for  next  phase  with  hardware  prototypes,  re¬ 
assessment  of  performance  risks  and  plans  for  thorough  testing  and  evaluation. 

Milestone  II  Decision  -  Approval  to  proceed  to  Full-scale  Development  -  all 
significant  risks  have  been  resolved,  technology  is  in  hand  to  conduct  engineering 
efforts 


Phase  II  -  Full-Scale  Development  Phase  -  engineering,  fabrication  and  full 
testing  of  the  system.  Low  Rate  Initial  Production  usually  is  shown  to  occur  in  this 
phase. 


Milestone  III  Decision  -  Approval  to  proceed  to  production  and  initial  deployment. 
In  practice,  this  decision  was  often  divided  into  IIIA  (Low  Rate  Initial  Production)  and  NIB 
(Full  Rate  Production)  reviews,  with  IIIA  frequently  delegated  to  the  individual  service 
Secretary. 

Phase  III  -  Full  Rate  Production  and  Initial  Deployment  Phase  -  production  and 
distribution  of  equipment,  and  providing  of  logistical  support;  product  improvements  may 
be  introduced. 

Milestone  IV  Decision  -  A  review  several  years  after  initial  deployment  to  ensure 
that  operational  readiness  and  support  objectives  are  being  achieved. 48 

Phase  IV  -  Operational  Support  Phase  -  during  which  the  system  is  continually 
operated  by  end  users  and  logistically  supported. 

Milestone  V  Decision  -  Major  upgrade  or  system  replacement  as  needs  might 
dictate. 


48  Fox,  J.  Ronald,  The  Defense  Management  Challenge:  Weapons  Acquisition,  Harvard  Business  School 
Press,  1988. 
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The  policy  provided  that  systems  undergoing  this  process  could  be  structured  by 
tailoring,  with  combined  phases  or  exempted  from  phases  of  the  entire  process  as 
appropriate. 


The  1991  Model 

In  1991,  a  major  revision  of  the  DoD  5000  series  was  released,  with  changes  to 
the  Life  Cycle  Systems  Management  Model.49  It  simplified  its  predecessor  by  lessening 
reviews  and  combining  phases  (Fig.  8.). 
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Fig.  8.  Defense  Acquisition  Milestones  and  Phases 

This  revision  of  the  framework  was  not  a  radical  departure  from  its  predecessor. 
But  the  “Full-Scale  Development”  phase  was  changed  to  Engineering  and 
Manufacturing  Development.  Phase  IV  Operations  and  Support  was  shown  as  an 
additional,  yet  not  distinctly  separate  phase. 50 


Determination  of  Mission  Need  -  not  a  phase  of  acquisition  but  a  period  of  need 
analysis  activities  ending  with  Milestone  0  -  Concept  Studies  Approval  and  Program 
Initiation. 


49  DoD  Directive  5000.1,  “Defense  Acquisition,”  February  23,  1991. 

50  USD(A)  Department  of  Defense  Instruction  5000.2,  Defense  Acquisition  Management  Policies  and 
Procedures,  February  23,  1991. 
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Concept  Exploration  and  Definition  Phase  -  ending  with  Milestone  I  -  Concept 
Demonstration  Approval. 

Demonstration  and  Validation  Phase  -  ending  with  Milestone  II  -  Development 
Approval. 

Engineering  and  Manufacturing  Development  Phase  -  ending  with  Milestone  III  - 
Production  Approval. 

Production  and  Deployment  Phase  -  overlaps  ongoing  Operations  and  Support, 
and  may  include  Milestone  IV  decision  reviews  for  Major  Modification  Approval  as 
reguired. 
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Fig.  9.  Defense  Systems  Acquisition  Management  Process5 


The  1996  revision  of  the  5000  series  was  published  after  a  rigorous  effort  to 
reform  the  defense  acguisition  system  during  the  first  half  of  the  Clinton  administration. 
The  model  (Fig.  9.)  is  streamlined  and  simplified  to  depict  only  four  phases  and  four 
decision  reviews.  LRIP  could  occur  on  either  side  of  Milestone  III  and  freguently  did 


51  Department  of  Defense  5000.2-R,  Mandatory  Procedures  for  Major  Defense,  Acquisition  Programs  and 
Major  Automated  Information  Systems,  1996. 
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occur  in  EMD  phase  as  a  service  Secretary  decision.  Demonstration  and  Validation 
Phase  was  renamed  Program  Definition  and  Risk  Reduction. 

Another  key  change  was  the  very  deliberate  change  in  the  declaration  of 
Program  Initiation  moving  from  Milestone  0  to  Milestone  I.  Program  Initiation  in  this 
series  would  mean  that  a  JROC-validated,  CAIV-based  Operational  Requirements 
Document  (ORD)  existed,  and  that  cost  schedule  and  performance  objectives  were 
defined  in  an  Acquisition  Program  Baseline,  a  current  threat  assessment  was 
conducted,  Analysis  of  Alternatives  (AOA)  was  performed,  supportability  analysis 
completed,  sufficient  life-cycle  resources  programmed,  and  that  an  acquisition  strategy 
was  in  place.  Program  Initiation  also  served  as  a  benchmark  of  OSD  interest  in 
annually  reporting  to  Congress,  per  10  USC  §  2220(b),  the  average  time  period 
between  program  initiation  and  Initial  Operational  Capability  (across  all  ACAT  I 
programs  of  any  commodity).  In  1 994,  the  average  was  1 1 5  months.52 

While  the  same  basic  kinds  of  activities  were  occurring  in  each  phase  of  this 
model  as  its  predecessor  (i.e.  concept  formulation,  prototyping,  modeling  and 
simulation,  advanced  development,  LRIP,  operational  testing,  etc,),  major  policy  thrusts 
towards  reform  were:  Integrated  Product  Process  Development  (IPPD),  program 
stability,  risk  assessment  and  management,  total  system  approach,  total  ownership 
costs  (TOC),  cost  as  an  independent  variable  (CAIV),  program  objectives  &  thresholds, 
non-traditional  acquisition,  tailoring,  continuous  improvement,  performance  (versus 
military)  standards  and  specifications,  electronic  commerce,  environmental 
management,  and  a  host  of  others. 

The  1996  5000  policy  series  only  consisted  of  DoDD  5000.1  (14  pages)  and  DoD 
5000. 2-R  (114  pages)  as  the  DODI  5000.2  was  eliminated.  Regarding  program  reviews 
or  decision  points,  the  PM  in  this  series  was  allowed  to  propose  the  number  and  level  of 
decision  reviews: 


52 


Ibid. 
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At  program  initiation,  and  after  consideration  of  the  views  of  the  Working- 
Level  Integrated  Product  Team  (IPT)  and  Overarching  IPT  members,  the 
PM  shall  propose,  and  the  MDA  shall  consider  for  approval,  the 
appropriate  milestones,  the  level  of  decision  for  each  milestone,  and  the 
documentation  needed  for  each  milestone.  This  proposal  shall  consider 
the  size,  complexity,  and  risk  of  the  program.  The  determinations  made  at 
program  initiation  shall  be  reexamined  at  each  milestone  in  light  of  then- 
current  program  conditions.53 

In  October  of  2000,  drafts  of  an  entirely  new  model  began  to  circulate. 
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Fig.  10.  Defense  Acquisition  Management  Framework5 


As  the  Clinton  administration  was  transitioning  out  in  late  2000,  the  current  model 
appeared  (Fig.  10.),  along  with  a  revision  of  the  5000  series.  There  were  major 
changes  from  the  previous  three,  largely  similar,  Pre-2000-era  models.  Described  as 
“three  milestones,  four  phases,”  there  are  actually  eight  distinct  program  activity  periods 
depicted,  including  the  pre-acquisition  activities,  and  a  total  of  six  reviews.  In  addition  to 
the  three  major  milestone  reviews  usually  seen,  interim  decision  and  progress  reviews 
had  been  added  within  each  of  the  major  phases  of  a  program. 


54  USD(AT&L)  Department  of  Defense  Instruction  5000.2,  Operation  of  the  Defense  Acquisition  System, 
October  23,  2000. 
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4. 7. 3. 2. 5.  Interim  Progress  Review.  The  purpose  of  an  interim  progress 
review  is  to  confirm  that  the  program  is  progressing  within  the  phase  as 
planned  or  to  adjust  the  plan  to  better  accommodate  progress  made  to 
date,  changed  circumstances,  or  both.  If  the  adjustment  involves  changing 
the  acquisition  strategy,  the  change  must  be  approved  by  the  MDA.  There 
is  no  required  information  necessary  for  this  review  other  than  the 
information  specifically  requested  by  the  decision-maker.55 

However,  there  was  an  indication  that  all  of  the  reviews  were  not  necessary, 
depending  on  where  a  program  might  enter  the  model.  DoDD  5000.1  said,  “Tailoring 
shall  be  applied  to  various  aspects  of  the  acquisition  system,  including  program 
documentation,  acquisition  phases,  the  timing  and  scope  of  decision  reviews,  and 
decision  levels.  Milestone  decision  authorities  shall  promote  flexible,  tailored 
approaches  to  oversight  and  review  based  on  mutual  trust  and  a  program's  dollar  value, 
risk,  and  complexity.56 

As  well,  each  of  the  six  “work  efforts”  had  its  own  entrance  and  exit  criteria.57 
Brief  descriptions  of  each  were: 

Concept  &  Technology  Development  Phase: 

Concept  Exploration  -  Paper  studies  of  alternative  concepts  for  meeting  a 
mission  need. 

Component  Advanced  Development  -  Development  of  subsystems/components 
that  must  be  demonstrated  before  integration  into  a  system,  and  concept/technological 
demonstration  of  new  system  concepts 

System  Development  &  Demonstration  Phase:  to  develop  a  system,  reduce 
program  risk,  ensure  operational  supportability,  design  for  producibility,  ensure 
affordability,  and  demonstrate  system  integration,  interoperability,  and  utility. 


56  USD(AT&L)  Department  of  Defense  Directive  5000.1 ,  The  Defense  Acquisition  System,  October  23, 
2000. 

57  Defense  Acquisition  Universite,  DAU  Faculty  Brief  Presentation,  November  2000. 
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System  Integration  -  for  reduction  of  integration  riskThe  architecture  is  complete, 
now  system  integration  is  applied  to  demonstrated  subsystems  and  components. 

System  Demonstration  -  to  complete  development  and  demonstrate  engineering 
development  models  with  combined  Development  and  Operational  testing. 

Production  and  Deployment  Phase: 

Production  Readiness,  LRIP  &  IOT&E-  for  Initial  Operational  Test  &  Evaluation 
and  Live  Fire  Test  &  Evaluation  of  production  representative  articles.  Manufacturing 
capability  will  be  verified  as  LRIP  Proceeds. 

Full  Rate  Production  &  Deployment  -  where  a  Beyond  LRIP  Report  may  be 
submitted  to  Congress  and  review  can  take  place  for  Full  Rate  production.  Receiving 
units  will  attain  full  operational  capability  as  deployment  of  the  system  continues  in  this 
phase. 

Operations  and  Support  Phase:  operation  and  support  of  the  system,  and  possibly 
block  improvements  as  required. 

The  first  acquisition  phase,  Concept  and  Technology  Development,  appeared  to 
be  a  combination  of  the  first  two  phases  of  the  older  acquisition  model.  Or  perhaps  the 
Program  Definition  and  Risk  Reduction  activities  were  to  be  split  between  Concept  and 
Technology  Development  and  System  Development  and  Demonstration  phases, 
depending  upon  activities  planned. 

The  DoDD  5000.1  iterated  strongly  that  formal  recognition  of  Program  Initiation 
was  shifting  to  the  right  in  this  new  model,  “4. 7. 2. 4. 2. 2.  A  favorable  Milestone  A 
decision  DOES  NOT  yet  mean  that  a  new  acquisition  program  has  been  initiated.”58 
Program  Initiation  was  definitely  now  shown  at  Milestone  B,  with  status  of  operational 
requirement  documentation,  technological  maturity,  and  resource  programming,  etc. 


58  USD(AT&L)  Department  of  Defense  Instruction  5000.2,  Operation  of  the  Defense  Acquisition  System, 
October  23,  2000. 
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commensurate  with  what  had  been  Milestone  I  in  the  1996  Model.  Rationale  was 
provided  for  this  as,  “The  practical  result  of  a  preference  for  more  mature  technology  is 
initiation  of  individual  programs  at  later  stages  of  development,  after  determination  of 
technology  maturity.”59 

The  policy  of  this  series  emphasized:  science  &  technology,  interoperability,  time- 
phased  requirements  for  evolutionary  acquisition,  integrated  test  &  evaluation,  logistics, 
transformation,  cost  as  a  military  requirement,  simulation  based  acquisition  and  other 
tenets.  With  re-emergence  of  DoD  Instruction  5000.2  (46  pages),  and  the  revised  DoD 
Directive  5000.1  (12  pages)  and  DoD  Regulation  5000. 2-R  (194  pages),  the  total 
amount  of  mandatory  guidance  totaled  252  pages.  However,  this  new  series  was  to  be 
short-lived,  as  abrupt  cancellation  of  the  series  occurred  on  30  October  2002. 
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Fig.  11.  Defense  Acquisition  Management  Framework 


60 


The  Deputy  Secretary  of  Defense  published  a  cancellation  memorandum  that 
sounded  critical  of  current  acquisition  policy: 


60  Secretary  of  Defense  Memorandum,  Defense  Acquisition,  Attachment  2,  Operation  of  the  Defense 
Acquisition  System,  October  30,  2002  (Interim  Guidance  5000.2,  p.  34). 
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I  have  determined  that  the  current  DoD  Directive  5000.1,  “The  Defense 
Acquisition  System,”  DoD  Instruction  5000.2,  “The  Operation  of  the 
Defense  Acquisition  System,”  and  DoD  5000. 2-R,  “Mandatory  Procedures 
for  Major  Defense  Acquisition  Programs(MDAPs)  and  Major  Automated 
Information  System  (MAIS)  Acquisition  Programs,”  require  revision  to 
create  an  acquisition  policy  environment  that  fosters  efficiency,  flexibility, 
creativity,  and  innovation.  Therefore,  by  separate  memorandum,  I  have 
cancelled  these  documents  effective  immediately. 

The  interim  guidance  attached  to  the  cancellation  memorandum  reduced  the 
DoDD  5000.1  document  from  12  to  6  pages  and  the  DoDI  5000.2  from  46  to  34  pages. 
A  new  set  of  policy  directives  and  instructions  was  to  be  published  within  120  days 
(actually  arriving  193  days  later). 

However,  the  acquisition  model  was  to  a  large  extent  the  same  as  in  the  2000 
series.  The  most  apparent  changes  to  it  were  (see  Fig.  1 1 .): 

■  The  name  of  the  Component  Advanced  Development  work  effort  was  changed  to 
Technology  Development. 

■  The  in-phase  decision  review  between  Concept  Exploration  work  effort  and 
Technology  Development  work  effort,  both  of  the  Concept  &  Technology 
Development  Phase,  was  eliminated. 

■  The  in-phase  review  in  SDD  was  now  defined  as  the  CDR,  one  of  several 
systems  engineering  technical  reviews  normally  conducted  by  the  Program 
Manager  -  and  roundly  criticized  by  the  DODIG  and  GAO  for  occurring  too 
soon.61 

The  cancelled  DoD  5000. 2-R  was  also  reissued  as  the  Interim  Defense 
Acquisition  Guidebook  dated  Oct  30,  2002,  and  became  discretionary  guidance.62 


61  Office  of  the  DoD  Inspector  General,  The  Critical  Design  Review  Process  for  Major  Defense  Acquisition 
Programs,  Audit  Report  Number  93-017,  November  5,  1992. 

62  Interim  Defense  Acquisition  Guidebook  October  30,  2002  (Formerly  the  DoD  5000.2-R,  Dated  April  5, 
2002). 


-35- 


The  Current  2003  Model 
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Fig.  12.  Defense  Acquisition  Management  Framework63 

The  current  2003  model  (Fig.  12.)  has  five  phases  and  six  potential  decision 
reviews.  Eight  total  distinct  activity  periods  exist  in  the  model,  including  pre-acquisition 
activity.  The  separation  of  Concept  &  Technology  Development  Phase  into  two  phases: 
Concept  Refinement  (previously  a  work  effort  called  Concept  Exploration)  and 
Technology  Development,  also  reintroduces  a  decision  review.  This  time,  however, 
Milestone  A  shifts  to  the  right  between  the  new  phases  -  at  the  entry  to  the  Technology 
Development  phase.  And  where  Milestone  A  was  before  is  now  the  point  of  Concept 
Decision  (CD),  which  is  required  for  entrance  into  the  Concept  Refinement  phase. 


The  entrance  and  exit  criteria  for  each  phase  and  work  effort  now  incorporate  the 
introduction  of  new  requirements  documents  from  the  Joint  Capabilities  Integration  and 
Development  System  (which  has  been  evolving  in  parallel  to  the  acquisition  system): 
the  Initial  Capabilities  Document  (ICD),  the  Capabilities  Development  Document  (CDD), 
and  the  Capabilities  Production  Document  (CPD).  Interestingly,  there  has  been  a  large 
state  of  flux  within  this  Decision  Support  System,  replete  with  changes  in  terminology 


63  USD(AT&L)  Department  of  Defense  Instruction  5000.2,  Operation  of  the  Defense  Acquisition  System, 
May  12,  2003. 
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and  decision  models.  The  overarching  series  of  instructions  governing  that 
requirements  generation  process  has  also  seen  two  major  revisions  in  the  past  three 

64 

years. 

The  current  5000  series  also  includes  language  on  evolutionary  acquisition  and 
spiral  development  taken  from  the  National  Defense  Authorization  Act  of  2003.  A  new 
requirement  for  a  Technology  Development  Strategy  has  been  introduced  to  satisfy 
Section  803,  Public  Law  107-314,  National  Defense  Authorization  Act  for  fiscal  year 
2003.  The  ICD  is  a  requirement  to  enter  the  Concept  Refinement  Phase  and  a 
Technology  Development  Strategy  (TDS)  principal  output  from  this  phase. 


64  CJCSM  3170.01  Operation  of  the  Joint  Capabilities  Integration  and  Development  System,  June  24, 
2003. 
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Understanding  the  Implicit  Aspects  of  the  Post-2000 
Era  Models 


Many  of  the  changes  from  the  straightforward  Pre-2000-era  framework  have  yet 
to  be  realized  across  the  DoD  acquisition  workforce.  Of  over  250  students  at  the  GS-13 
through  15  level  that  we  have  surveyed  across  two  services  and  four  major  acquisition 
commands,  the  vast  majority  have  been  unfamiliar  with  the  most  significant  changes. 
Most  cannot  name  from  memory  the  latest  phases  and  milestones.65  The  shift  between 
the  gradually  changing  1987-1996  models  and  the  three  rapidly  changing  2000-era 
versions  has  been  dramatic.  Even  without  the  succeeding  adjustments  in  2002  and 
2003,  there  are  many  explicit  and  implicit  aspects  to  this  model  that  are  particularly 
noteworthy  for  discussion  because  of  their  significant  consequences  for  acquisition 
managers.  The  2000-era  and  forward  DoD  5000  series  has  promulgated  a  program 
framework  with  more  phases,  more  decision  reviews,  and  with  some  of  those  reviews 
elevated  to  a  higher  level.  The  relative  placement  of  milestone  reviews  with  other 
program  activities  is  also  significant. 

Number  and  Level  of  Milestone  and  Program  Decision  Reviews: 

The  most  apparent,  and  perhaps  least  significant,  change  between  eras  was 
from  numerical  to  alphabetical  designation  of  major  milestone  reviews.  A  more  subtle 
and  important  change  was  the  appearance  of  divided  phases  and  within-phase  decision 
and  progress  reviews.  With  the  latest  release  of  the  regulatory  series,  these  additional 
sub-phases  or  “work  efforts,”  along  with  “pre-acquisition  activities”  have  brought  the 
total  number  of  distinct  activity  intervals  to  eight,  with  as  many  as  five  phases  and  six 
decision  reviews  -  more  than  at  any  time  past.  The  work  efforts  are  not  called  “phases” 
however.  Each  of  these  efforts  has  its  own  entrance  and  exit  criteria,  making  them  more 
in  practice  like  a  distinct  phase  of  acquisition. 


65  Author’s  unpublished  results  of  student  surveys  taken  during  the  course:  MN4366  Program 
Management  and  Leadership  as  part  of  the  Advanced  Acquisition  Program,  Graduate  School  of 
Business  and  Public  Policy,  Naval  Postgraduate  School,  Monterey,  California,  2001-2003. 
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Reviews  are  described  in  the  current  policy  to  be  decision  points  where  decision 
makers  can  either  stop,  extend  or  grant  permission  to  proceed  into  the  next  phase. 
Program  reviews  of  any  kind  at  the  OSD  level  have  a  significant  impact  on  program 
offices.  Much  documentation  must  be  prepared  and  many  preparatory  meetings  are 
conducted  enroute  to  the  ultimate  review.  And  while  non-milestone  reviews  are 
generally  considered  to  be  lesser  in  scope  of  effort  to  prepare  for,  a  considerable 
amount  of  effort  managing  the  decision  process  is  still  expended.  Documentation 
required  for  various  milestone  and  decision  reviews  is  shown  below  (Fig.  13.): 
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66 


INFORMATION  FOR  DECISION  REVIEWS 


Required  Information 

Milestone/Review 

CD 

A 

B 

c 

FRP 

Acquisition  Decision  Memorandum  (ADM)  (Note  6) 

X 

X 

X 

X 

X 

Acquisition  Proqram  Baseline  (APB)  (Note  6) 

X 

X 

X 

Acquisition  Strateqy  (See  page  5)  (Note  6) 

X 

X 

X 

Affordability  Assessment 

X 

X 

Analysis  of  Alternatives  (AOA)  (Note  4&6 ) 

X 

X 

X 

X 

AOA  Plan 

X 

Benefit  Analysis  &  Determination  (Note  7) 

X 

X 

Beyond  LRIP  Report  (note  2) 

X 

Capabilities  Development  Document  (CDD)  (Note  3  &6) 

X 

Capabilities  Production  Document  (CPD)  (Note  3) 

X 

Certification  of  Compliance  with  Clinger-Cohen  (MAIS  only) 

X 

X 

X 

X 

Certification  of  Compliance  with  Financial  Management 

Enterprise  Architecture  (FM  MAIS  only) 

X 

X 

X 

X 

C4I  Support  Plan  (Notes  1  &  6/ 

X 

X 

C4I  Supportability  Certification 

X 

Clinger-Cohen  Act  Compliance  (MAIS)  (Note  6) 

X 

X 

X 

X 

Competition  Analysis  (depot-level  maintenance  rule)  (Notes  1  &  5) 

X 

Compliance  with  Strategic  Plan 

X 

X 

Component  Cost  Analysis  (MAIS;  optional  MDAP)  (Note  6) 

X 

X 

X 

Consideration  of  Technology  Issues 

X 

X 

X 

Cooperative  Opportunities  (Note  1) 

X 

X 

Core  Loqistics/Source  of  Repair  Analysis  (Note  1) 

X 

X 

Cost  Analysis  Requirements  Description  (MDAP  &  MAIS)  (Note  6) 

X 

X 

X 

Economic  Analysis  (MAIS) 

X 

X 

X 

Exit  Criteria 

X 

X 

X 

Industrial  Capabilities  (n/a  AIS)  (Note  1) 

X 

X 

Independent  Cost  &  Manpower  Estimate  (MDAPs;  n/a  MAIS) 

X 

X 

X 

Independent  Technology  Assessment  (ACAT  ID  only) 

X 

X 

Initial  Capabilities  Document  (ICD)  (Note  6) 

X 

X 

X 

X 

Interoperability  Certification 

X 

IT  Certification  (MAIS) 

X 

X 

X 

Live  Fire  T&E  Waiver  (covered  systems)(note  2) 

X 

Live  Fire  T&E  Report  (covered  systems) (note  2) 

X 

LRIP  Quantities  (n/aAIS) 

X 

Market  Research 

X 

X 

Operational  Test  &  Evaluation  Results 

X 

X 

X 

Post  Deployment  Performance  Review 

X 

Proqram  Protection  Plan  (Note  1) 

X 

X 

Pqm  Environ,  Safety  &  Ocup  Health  (w/NEPA  schedule)  (Note  6 ) 

X 

X 

X 

Registration  of  Msn  Critical  &  Msn  Essential  Info  Sys  (Note  6) 

X 

X 

Spectrum  Certification  Compliance  (Note  4) 

X 

System  Threat  Assessment  (Note  6) 

X 

X 

X 

Technology  Development  Strateqy 

X 

X 

X 

Selected  Acquisition  Report  (MDAPsjfAfofe  6) 

X 

X 

X 

Technology  Readiness  Assessment  (Note  6) 

X 

X 

Test  &  Evaluation  Master  Plan  (eval  strateqy  due  MSA) 

X 

X 

X 

Note  1 .  Also  summarized  in  acquisition  strategy  Note  5.  Milestone  C  if  program  initiation 

Note2.  OSD  T&E  Oversight  programs  only  Note6.  Program  Initiation  for  ships 

Note  3.  ICD,  ODD  &  CPD  replace  MNS  &  ORD  Note  7.  If  no  Milestone  B,  submit  at  Milestone  C 

Note  4.  For  MDAP  A,  B,  C;  For  MAIS  A,  B  &  FRP 

Fig.  13.  Documentation  for  Decision  Reviews66 


Defense  Acquisition  Universite,  Program  Managers  Toolkit,  13th  edition  (Ver  1.0),  June  2003. 


-40- 


The  latest  edition  of  the  Program  Managers  Toolkit  shows  a  figure  that  has  long 
been  familiar  to  Program  Managers,  showing  a  six-month  timeline  of  activities  leading  to 
a  review.  This  same  six-month  timeframe  for  preparation  of  an  OSD-level  review  has 
been  unchanged  for  many  years  (Fig.  14.). 

DAB  TIMELINE  MILESTONES  B,  C  &  FRPDR 


Fig.  14.  Timelines  for  a  Defense  Acquisition  Board  Review67 

What  this  simple  schematic  cannot  fully  convey  is  the  amount  of  meetings  and 
preparatory  briefings  to  staff  members  and  committees.  Some  representatives  from 
program  management  offices  keep  an  accounting  of  travel  and  labor  costs  associated 
with  a  milestone  reviews  for  an  MDAP  system.  While  only  anecdotal  data  was  available 
for  this  research,  it  is  easy  to  surmise  that  a  substantial  amount  of  program  office 
funding  would  be  expended  on  support  contractor  assistance  with  supporting  analyses 


67 


Ibid. 
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and  documentation,  as  well  as  frequent  travel  to  the  Pentagon,  and  other  associated 
expenses  in  preparation  for  high-level  reviews.68  As  of  this  writing,  there  are  a  total  of 
25  MDAP  programs  in  the  Department  of  Defense. 

And  though  little  written  guidance  yet  exists  for  the  new  Design  Readiness 
Review  (DRR)  in  the  midst  of  the  SDD  phase,  it  can  be  presumed  to  be  an  extensive 
effort.  This  review  evolved  from  an  in-phase  I  PR  in  the  2000  series  to  a  Critical  Design 
Review  in  the  2002  Interim  Guidance  model  to  its  current  name.  Such  a  review  at  OSD- 
level  is  in  keeping  with  the  increased  emphasis  now  being  placed  on  technological 
assessment  mentioned  earlier.  What  is  significant  to  PMs  is  that  such  a  review,  at  least 
in  the  name  of  Critical  Design  Review,  was  previously  one  of  several  program-level 
technical  reviews  -  chaired  by  the  PM  -  within  a  disciplined  systems  engineering  effort. 

It  is  an  extensive  review  that  can  span  days  in  length.  How  this  review  will  be 
conducted  remains  to  be  seen,  as  of  this  writing,  but  it  seems  to  be  an  entirely  new 
approach  to  elevate  a  technical  review  to  service  or  OSD  level. 

With  Evolutionary  Acquisition  as  the  preferred  strategy,  notional  systems  are  now 
shown  as  shorter  developments  (in  SDD)  with  iterative  Milestone  B-to-C  cycles.  The 
new  DoDI  5000.2  prescribes  that,  “In  an  evolutionary  acquisition  program,  the 
development  of  each  increment  shall  begin  with  a  Milestone  B,  and  production  resulting 
from  that  increment  shall  begin  with  a  Milestone  C.”69  Thus,  program  managers  can 
expect  to  undergo  the  reviews  determined  appropriate  for  the  initial  increment  of 
development  in  their  program,  as  well  as  reviews  specified  for  the  follow-on  increments. 

The  most  recent  published  guidance  shows  one  example  of  a  system  with  no 
less  than  fourteen  reviews  in  its  first  eleven  years  from  Concept  Decision  (see  Fig.  15.). 


68  Author’s  unpublished  interview  with  an  anonymous  representative  from  a  major  program  office  going 
through  a  milestone  review,  Naval  Postgraduate  School,  Monterey,  California,  February  19,  2003. 

69  USD(AT&L)  Department  of  Defense  Instruction  5000.2,  Operation  of  the  Defense  Acquisition  System. 
May  12,  2003. 
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PROGRAM  STRUCTURE/SCHEDULE  (EXAMPLE) 
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Fig.  15.  Example  of  Program  Structure  Showing  Two  Successive  Development  Increments  and  Their 
Associated  Reviews70 


Program  Initiation  Moves  Further  to  the  Right: 

In  all  three  Post-2000-era  models,  Milestone  B  is  now  the  point  of  “program 
initiation,”  and  although  some  early  graphic  depictions71  of  the  new  model  showed  a 
correlation  to  Milestone  I  of  the  1996  version,  this  milestone  actually  correlates  more 
closely  to  the  old  Milestone  II  in  terms  of  system  technical  maturity  (and  other  program 
events)  under  this  latest  era  of  models. 

For  transition  of  programs  already  underway,  the  following  guidance  was  given  in 
October  of  2000: 

4.5.  Programs  planned  in  accordance  with  the  1996  version  of  DoDD 
5000.1  (reference  (g))  and  DoD  5000. 2-R  (reference  (h))  shall  be 
executed  in  accordance  with  approved  program  documentation.  That 
documentation  shall  not  be  updated  solely  to  satisfy  the  requirements  of 
this  Instruction.  Programs  already  approved  to  enter  Engineering  and 


70  Defense  Acquisition  Universite,  Program  Managers  Toolkit,  13th  edition  (Ver  1.0),  June  2003. 

71  Defense  Acquisition  Universite,  DAU  Faculty  Brief  Presentation,  November  2000. 
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Manufacturing  Development  shall  continue  to  follow  the  sequence  of 
milestones  established  in  their  program  documentation.  The  new  policies 
in  this  Instruction,  including  the  new  decision  points  and  phases,  shall  be 
applied  to  efforts  that  have  not  yet  been  approved  as  acquisition  programs 
(usually  pre-Milestone  I)  unless  otherwise  directed  by  the  MDA.  The  new 
policies  in  this  Instruction,  including  the  new  decision  points  and  phases, 
shall  be  applied  to  programs  that  are  post-Milestone  I  but  that  are  not  yet 
in  Engineering  and  Manufacturing  Development  at  the  discretion  of  the 
MDA.  For  purposes  of  complying  with  applicable  laws,  Milestone  A  will 
serve  as  Milestone  0;  Program  Initiation,  when  it  occurs  at  or  during 
Component  Advanced  Development,  will  serve  as  Milestone  I;  Milestone  B 
will  serve  as  Milestone  II;  Milestone  C  will  serve  as  the  Low-Rate  Initial 
Production  decision  point;  and  the  Full-Rate  Production  Decision  Review 
will  serve  as  Milestone  III.  In  addition,  System  Development  and 
Demonstration  will  serve  as  Engineering  and  Manufacturing 
Development.72 

This  passage  communicates  some  degree  of  resultant  complexity  involved  with 
changing  terminology  and  sequencing  of  milestones  and  reviews,  and  of  programs 
proceeding  under  multiple  sets  of  rules  and  lexicon.  At  least  one  service  published 
explanatory  guidance  for  its  programs  to  help  delineate  which  set  of  rules  would  apply 
to  particular  programs,73  resulting  in  the  use  of  two  acquisition  models  for  a  time. 

Moving  program  initiation  “further  to  the  right”  in  program  terminology  allows  for 
more  time  to  be  spent  firming  requirements,  assuring  that  funding  is  in  place,  and 
development  of  an  acquisition  strategy  before  declaration  as  a  formal  program. 

Perhaps  the  thinking  is  that  a  later  official  start  of  a  program  will  assure  an  earlier  finish, 
as  it  were.  But  to  not  acknowledge  (via  “program  initiation”)  that  a  program  is  underway 
in  two  successive  acquisition  periods  beyond  need  analysis  period  seems  to  this  author 
somewhat  illogical  or  disingenuous. 


72  USD(AT&L)  Department  of  Defense  Instruction  5000.2,  Operation  of  the  Defense  Acquisition  System, 
October  23,  2000. 

73  Assistant  Secretary  of  the  Army,  Acquisition,  Technology,  and  Logistics,  The  New  Defense  Acquisition 
Policies  and  Army  Positions,  December  2000. 
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Technological  Maturity  before  Program  Commitment: 

The  Milestone  B  distinction  was  (and  still  is)  important  because  it  places  program 
initiation  at  the  point  where  the  commencement  of  advanced  development,  not 
prototyping,  will  occur.  The  1996-era  policy  designated  program  initiation  at  Milestone  I, 
the  onset  of  PDRR,  and  in  the  1991 -era  policy  it  was  even  earlier  -  at  Milestone  0.  This 
deferral  of  formal  program  recognition  until  a  later  stage  of  technical  maturity  is  an 
explicit  delay  of  departmental  commitment.  The  formal  declaration  of  product  (versus 
technology)  development  likely  stems  from  two  GAO  Reports  (reports  number  02-39 
and  99-162)  that  recommended  increased  product  knowledge  prior  to  business 
commitment.  And  recall  as  well  the  reporting  requirement  to  congress  on  the 
development  time  between  program  initiation  and  initial  operational  capability.  Again,  a 
delay  in  declaration  of  program  initiation  will  at  least  appear  to  shorten  cycle  time  if 
advanced  development  and  production  timelines  remain  unchanged. 

As  with  previous  policy  throughout  multiple  versions  of  the  DoD  5000  series  on 
tailoring  of  acquisition  programs,  it  is  emphasized  again  that,  appropriate  to  their 
concept  and  technology  maturity,  programs  can  enter  the  process  at  various  points  in 
the  new  model.  Language  in  DoD  5000.2  supports  the  policy  thrust  that  technical 
assessment  will  be  an  important  part  of  program  assessment: 

3. 7. 2. 2.  Technology  developed  in  S&T  or  procured  from  industry  or  other 
sources  shall  have  been  demonstrated  in  a  relevant  environment  or, 
preferably,  in  an  operational  environment  to  be  considered  mature  enough 
to  use  for  product  development  in  systems  integration.  Technology 
readiness  assessments,  and  where  necessary,  independent  assessments, 
shall  be  conducted.  If  technology  is  not  mature,  the  DoD  Component  shall 
use  alternative  technology  that  is  mature  and  that  can  meet  the  user’s 
needs.74 

The  interim  guidebook  prescribes  the  use  of  definitive  Technology  Readiness 
Levels  or  other  measuring  tools  to  be  assigned  to  critical  technologies  of  the  developing 


74  USD(AT&L)  Department  of  Defense  Instruction  5000.2,  Operation  of  the  Defense  Acquisition  System, 
May  12,  2003. 
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system  by  Component  S&T  Executive  and  passed  up  the  chain.  These  too  had  been 
emphasized  earlier  by  the  GAO  (see  report  number  02-39). 

Clearly,  a  frustration  of  the  past  has  been  the  setbacks  and  resultant  lengthening 
of  advanced  development  phases  from  efforts  to  employ  the  very  latest  in  emerging 
technology.  But  it  can  be  argued  that  time  saved  in  a  shorter  advanced  development 
(SDD)  phase  can  only  result  from  more  time  spent  in  the  preceding  phases  of  Concept 
Refinement  and  Technology  Development,  with  uncertainty  of  any  genuine  program 
cycle  time  reduction. 

In  the  past,  technology  development  during  the  advanced  development  (EMD) 
phase  was  blamed  for  undue  costs  and  lengthening  of  this  phase.  But  a  very  real 
concern  may  now  be  that  —  unless  SDD  is  greatly  shortened  -  attaining  technological 
maturity  at  Milestone  B  instead  of  C  guarantees  the  fielding  of  “yesterday’s  technology 
tomorrow.” 

In  other  words,  there  is  a  very  real  but  somewhat  understated  distinction  between 
what  was  Milestone  III  under  the  1996  model  and  what  is  now  Milestone  C  under  the 
Post-2000  era  models,  beyond  that  of  LRIP  and  Full  Rate  Production.  Evolutionary 
acquisition  under  the  new  model  prescribes  the  initiation  of  low-rate  production  of  an 
80%  solution  at  Milestone  C  as  the  preferred  approach.  In  order  to  achieve  the  100% 
capability  solution  desired  in  the  same  time  frame  as  would  be  planned  under  the 
single-step  acquisition  strategy,  the  model  is  perhaps  more  accurately  depicted  as 
below  (Fig.  16): 
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Fig.  16.  Actual  Comparison  of  1996  and  Post-2000-era  Acquisition  Framework  Models 

Again,  what  is  most  apparent  here  is  the  increased  number  of  decision  reviews, 
as  well  as  the  concurrent  activities  involved  in  managing  the  follow-on  development 
increment  and  its  requisite  reviews  as  well.  Assuming  advanced  development  (SDD)  is 
indeed  shortened,  and  further  assuming  that  concept  and  early  prototyping  phases  are 
no  longer  than  before,  the  time  and  effort  on  control  activities  appears  almost  certainly 
excessive  within  the  same  system  delivery  timeline. 


Funding  Implications: 

Post-2000-era  policy  requires  full  funding  for  programs  no  later  than  Milestone  B, 
and  transition  funding  is  needed  to  support  any  later  entry  into  the  acquisition  process. 
The  long  held  definition  of  “full  funding”  (pertaining  to  the  total  cost  associated  with  an 
authorized  quantity  of  militarily  usable  end  items  for  a  procurement  within  the  fiscal 
year)  was  expanded  to  have  a  second  meaning: 
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A  requirement  for  formal  program  initiation  of  an  acquisition  program.  In 
this  sense,  full  funding  means  having  an  approved  current  (and  projected) 
resource  stream  to  execute  the  program,  i.e.,  program  funding  is  included 
both  in  the  budget  and  in  the  out-years  of  the  FYDP  sufficient  to  cover  the 
current  and  future  efforts  described  in  the  acquisition  strategy  (emphasis 
mine).  Funding  requirements  will  be  adjusted  at  least  annually  as  the 
program  advances  through  its  life  cycle.75 

This  expansion  of  this  term  may  serve  as  some  assurance  to  OSD  that  programs 
will  be  less  likely  to  exceed  program  estimates  if  only  initiated  when  all  forecasted 
resources  are  in  place.  DoDI  5000.2  states  that: 

Transition  into  SDD  also  requires  full  funding  (i.e.,  inclusion  of  the  dollars 
and  manpower  needed  for  all  current  and  future  efforts  (emphasis  mine)  to 
carry  out  the  acquisition  strategy  in  the  budget  and  out-year  program), 
which  shall  be  programmed  when  a  system  concept  and  design  have 
been  selected,  a  PM  has  been  assigned,  requirements  have  been 
approved,  and  system-level  development  is  ready  to  begin.76 

However,  with  regard  to  Evolutionary  Acquisition  as  the  preferred  approach  to 
satisfying  operational  needs,  there  are  two  development  processes  that  may  be 
implemented:  (a)  Incremental  Development  -  where  the  end-state  requirement  is 
known,  and  requirement  will  be  met  overtime  in  several  increments,  and  (b)  Spiral 
Development  -  where  desired  capability  is  identified,  but  end-state  requirements  are  not 
known  at  program  initiation,  and  requirements  for  future  increments  are  dependent  upon 
technology  maturation  and  user  feedback  from  initial  increments.  Of  these  two 
processes,  Spiral  Development  shall  be  the  preferred  process. 

If  we  recall  Wideman’s  caution  about  indefinite  numbers  of  spirals,  a  special 
challenge  is  presented  for  obtaining  realistic  full  funding  estimates  for  programs  with 
uncertain  requirements  and  numbers  of  increments.  If  indeed,  shorter  cycles  are 
facilitated  by  evolutionary  acquisition,  skillful  financial  management  (programming  and 


75  Defense  Acquisition  Universite,  Glossary  -  Defense  Acquisition  Acronyms  and  Terms,  10th  Edition, 
January  2001. 

76  USD(AT&L)  Department  of  Defense  Instruction  5000.2,  Operation  of  the  Defense  Acquisition  System, 
May  12,  2003. 
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budgeting)  will  be  required  to  effectively  enable  the  availability  of  funding  as 
requirements  for  successive  blocks  are  realized. 

The  Significance  of  Milestone  C,  and  IOT&E  after  the  LRIP 
Decision: 

The  designation  of  LRIP  now  as  an  OSD  decision  for  MDAPs  in  many  cases 
heightens  the  level  of  this  review  (and  the  associated  effort  for  same  discussed  earlier). 
As  mentioned  before,  Low  Rate  Initial  Production  was  often  delegated  to  service 
Secretaries  and  was  a  concurrent  activity  within  the  advanced  development  phase.  The 
advanced  development  paradigm  is  now  changed:  there  will  continue  to  be 
development  activity  after  the  initiation  of  production,  but  all  production  is  now  viewed 
as  a  separate  phase  of  the  system’s  life  cycle.  Production  has  traditionally  been  the 
phase  where  larger  portions  of  program  funds  are  spent,  with  the  following  Operations 
and  Support  phase  even  larger. 

Also,  while  not  specifically  stated,  the  placement  of  IOT&E  after  the  Milestone  C 
decision  might  imply  to  some  that  only  LRIP  articles  are  to  be  used  in  Initial  Operational 
Test  and  Evaluation.  But  the  DoD  5000.2  states  that  production  or  production 
representative  articles  may  be  used,  so  there  is  no  apparent  preclusion  from  using  SDD 
articles.  The  Operational  Test  and  Evaluation  community  has  long  attempted  to  require 
only  production  representative  articles  to  be  used  in  operational  testing.  However,  the 
concurrency  of  engineering  activities  to  exploit  task  lead-lag  times  for  schedule 
reduction  has  often  thwarted  this  objective.  IOT&E  was  previously  conducted  during  the 
advanced  development  phase.  It  was  viewed  as  an  event  that  proved  out  development 
by  testing  the  completed  system  in  an  operational  environment  with  end  users. 

Programs  had  sometimes  transitioned  into  Low  Rate  Initial  Production,  and  had 
simultaneously  gone  into  operational  test  with  engineering  articles  from  the  advanced 
development  phase. 

LRIP  is  now  part  of  the  production  phase.  And  if  LRIP  articles  are  to  be  used  as 
test  items  for  IOT&E,  program  managers  will  have  to  intensively  manage  (in  order  to 
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minimize)  the  time  period  between  permission  to  award  the  production  contract, 
produce,  and  receive  deliverables  to  use  in  IOT&E,  and  subsequently  support  a  Full- 
Rate  Production  Review.  As  in  the  past,  DOT&E  specifies  how  many  test  articles  will 
be  used  in  IOT&E,  and  must  render  a  supportive  Beyond  LRIP  report  directly  to 
congress  before  programs  can  proceed  with  Full  Rate  Production. 

Impact  upon  the  Requirements  Generation  System: 

The  Requirements  Generation  System  employs  Chairman  of  the  Joint  Chiefs  of 
Staff  instructions  and  manuals  for  policy  guidance  regarding  processes  in  their  purview. 
The  CJCSI  31 70.01  A  of  10  August  1999  showed  linkage  to  the  Acquisition  System  with 
the  following  graphical  representation  of  Joint  Requirements  Oversight  Council 
meetings  in  support  of  Defense  Acquisition  Board  decision  reviews  (Fig.  17.). 
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Fig.  17.  Requirements  Generation  and  Acquisition  System  Interface  3170. 01A,  August  1999 

The  next  version  of  the  CJCSI  31 70.01  B  of  15  April  2001  displayed  the  new 
model  (Fig.  18.)  and  allowed  that  there  would  be  two  models  for  JROC  and  Acquisition 
interfacing:  “Programs  planned  in  accordance  with  the  1999  version  of  the  DOD  5000 
series  will  be  executed  per  their  approved  program  documentation.” 
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Determination  of  Mission  Concept  &  Techno|ogy  system  Development  Production  &  Deployment 
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Fig.  18.  Requirements  Generation  and  Acquisition  System  Interface  3170.01  B,  April  2001 

Issuance  of  the  CJCSI  31 70.01  C  on  24  June  03  simplifies  their  process,  showing 
only  three  affirmations  of  requirements  via  JROC  in  support  of  the  JCIDS  and 
acquisition  processes  (and  is  in  variance  with  Program  Managers  Toolkit  showing 
JROCs  in  support  of  Milestone  B,  C,  and  FRP,  Fig.  19.). 
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Fig.  19.  Requirements  Generation  and  Acquisition  System  Interface  CJCSI  31 70.01  C,  June  2003 
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What  is  very  apparent  in  this  new  model  for  requirements  generation  is  its 
illustration  of  newly  established  documents  that  drive  the  acquisition  system,  and  where 
they  will  each  emerge  in  the  parallel  processes.  The  ICD  generally  correlates  to  the 
long-established  MNS.  The  CDD  generally  correlates  to  the  long-established  ORD. 

The  CPD,  however,  is  a  new  reflection  of  what  will  be  the  then-achievable  requirements 
that  the  combined  communities  agree  to  produce.  This  is  a  new  move  toward 
requirements  flexibility  that  reflects  what  developers  have  struggled  with  for  some  time: 
requirements  become  discovered  and  more  fully  understood  as  the  system  matures. 
Being  locked  into  unattainable  requirements  has  proven  costly.  Requirements  have 
often  been  both  difficult  to  attain  and  perhaps  as  difficult  to  change.  The  new  CJCS 
instruction  therefore  provides  for  more  flexibility  in  the  requirements  determining 
process. 

Also  obvious  in  the  model  is  a  top-down  approach  to  requirements  that  is  intrinsic 
in  the  accompanying  written  policy  guidance.  While  well  beyond  the  scope  of  this 
research  effort,  it  must  be  pointed  out  that  a  significant  step  has  been  taken  in  this  new 
policy  to  centralize  control  of  the  requirements  process,  in  an  effort  to  ensure  not  only 
consolidation  and  optimization  of  investment  efforts  that  come  from  this  process,  but 
interoperability  between  systems  and  services  as  well. 

On  the  whole,  the  Post-2000-era  acquisition  models  prescribe  a  very  new 
paradigm,  and  only  time  can  inform  us  whether  Deputy  Secretary  Wolfowitz’s  goals  of 
program  management  flexibility  and  innovation  have  been  achieved.  No  program  has 
yet  gone  through  the  entire  model,  and  none  will  for  many  years  to  come. 
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Centralized  Control  of  Defense  Acquisition  Programs 


The  U.S.  Constitution  clearly  established  civilian  control  of  the  military  and  spells 
out  the  powers  and  responsibilities  of  Congress  with  regard  to  it.  The  1947  National 
Security  Act  and  subsequent  amendments  established  civilian  control  of  the  military 
within  a  newly  created  Department  of  Defense,  and  there  has  since  been  an  ongoing, 
competitive  tension  between  military  and  civilian  members  over  power  and  control  even 
within  this  organization.  The  centralized  authority  of  the  Secretary  of  Defense  and  his 
staff  was  further  strengthened  in  later  amendments,  particularly  in  the  tenure  of  Robert 
McNamara  (1961-68),  renowned  for  his  institution  of  PPBS,  etc.77 

The  Goldwater-Nichols  Act  of  1986  shifted  some  power  to  the  combatant 
commanders  in  formulation  of  equipment  requirements  via  the  JROC,  but  also  shifted 
military  and  civilian  (mostly  military)  program  manager  personnel  to  the  control  of  the 
civilian  led  service  secretariats.  It  too  led  the  way  for  a  separate  professionalized 
acquisition  corps  that  would  develop  experienced  and  educated  program  managers  to 
administer  their  programs  efficiently  and  effectively. 

Nevertheless,  time  spent  “managing  the  bureaucracy”  has  remained  an 
encumbrance  to  PMs.  Back  in  1988-89,  military  research  fellows  studying  commercial 
practices  at  the  Defense  Systems  Management  College  wrote  about  an  imbalance  of 
authority  between  PMs  and  the  OSD  staff.78  Of  eleven  improvements  they 
recommended  to  the  acquisition  process,  number  three  on  their  list  was,  “Reduce  the 
number  and  level  of  program  decision  milestones.”  Showing  the  1987  model,  they 
recommended  that  only  one  of  the  then  five  reviews  be  conducted  at  OSD  level:  the 
review  for  advanced  development.  They  quoted  the  1986  Packard  Commission’s 
conclusions,  which  said,  “He  (the  PM)  should  be  fully  committed  to  abide  by  the 


77  Fox,  J.  Ronald,  The  Defense  Management  Challenge:  Weapons  Acquisition,  Harvard  Business  School 
Press,  1988. 

78  Defense  Systems  Management  College,  Using  Commercial  Practices  in  DoD  Acquisition,  December 
1989. 
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program’s  specified  baseline  and,  so  long  as  he  does  so,  the  Defense  and  Service 
Acquisition  Executives  should  support  his  program  and  permit  him  to  manage  it.  This 
arrangement  would  provide  much  needed  program  stability.”79 

Going  back  even  further  to  1981 ,  Defense  Secretary  Casper  Weinberger  and  his 
Deputy  Secretary  Frank  Carlucci  had  instituted  thirty-two  acquisition  reforms  that  took 
aim  at  centralized  control  by  the  senior  civilian  advisors  in  the  Pentagon.  He 
streamlined  the  milestone  decision  review  process  at  OSD  level  from  four  milestone 
reviews  to  only  two.  But  as  Fox  points  out,  there  are  no  sovereign  powers  in 
Washington,  but  many  independent  ones,  capable  of  impeding  initiatives  of  others.80 

Indeed  the  Defense  Acquisition  Board  is  a  powerful  decision  making  board  when 
it  convenes,  but  until  it  does,  it  is  a  diverse  committee  of  disparate  interests  with  powers 
of  “no”  among  many  individuals  and  powers  of  “yes”  to  none.  Frequent  reviews  may 
lead  to  numerous  program  adjustments,  much  as  is  done  now  with  resource  shuffling 
with  program  funding.  The  time  and  effort  spent  in  managing  the  bureaucracy,  versus 
the  program,  is  a  major  activity  of  PMs,  and  repeated  adjustments  are  opposed  to 
program  stability. 

Mentioned  earlier  was  that  contingency  theory  encourages  senior  leaders  to  find 
the  best  fit  for  their  organization’s  structure  to  its  environment,  understanding  that  some 
situations  might  call  for  rigid  bureaucratic  structure  while  others  might  require  a  more 
flexible,  organic  one.  The  concept  of  control  is  also  a  cornerstone  of  cybernetics:  the 
study  of  organizations,  communications  and  control  in  complex  systems.  It  focuses  on 
looped  feedback  mechanisms,  where  the  controller  communicates  to  the  controlled 
what  is  the  desired  future  state,  and  the  controlled  communicates  to  the  controller 


79  Packard  Commission,  A  Quest  for  Excellence,  Final  Report  to  the  President,  1 986. 

80  Fox,  J.  Ronald,  The  Defense  Management  Challenge:  Weapons  Acquisition,  Harvard  Business  School 
Press,  1988. 
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information  with  which  to  form  perceptions  for  use  in  comparing  states.  The  controller 
then  communicates  (directs)  purposeful  behavior.81 

The  fundamental  need  for  communications  constrains  the  options  for  control, 
making  the  communications  architecture  a  critically  important  feature  of  the  control 
system.  It  is  often  heard  that  with  communications  in  today’s  information  age  warfare, 
we  seek  to  “act  within  the  enemy’s  decision  cycle.”  For  acquisition  decision  makers,  the 
information  architecture  is  the  command  and  control  hierarchy  within  our  bureaucracy. 
And  the  decision  cycle  in  the  course  of  a  program  (shown  in  Fig.  14)  still,  after  many 
years,  reflects  180  days  of  typical  preparation  lead-time  fora  decision  review. 

Mises,  Hayek  and  Kirzner,  in  their  work  described  a  “knowledge  problem”  with 
regard  to  centralized  planning  and  control: 

The  knowledge  problem  stems  from  the  fact  that  a  planner,  especially  a 
central  planner,  may  fail  to  achieve  an  attainable  goal  because  of  the 
inadequacies  of  the  planner’s  knowledge.  Central  planners  are  usually 
unaware  of  their  own  ignorance  concerning  the  facts  relevant  to  their 
social  plans.  Because  the  central  planner  cannot  know  everything  about 
the  problem  he  is  confronted  with,  his  knowledge  must  take  the  form  of 
what  he  thinks  he  knows  about  the  dispersed  bits  of  knowledge  that  can 
be  obtained.  He  uses  these  bits  of  dispersed  knowledge  to  implement  his 
social  plan,  but  he  may  be  unaware  of  other  bits  of  knowledge  that  could 
have  been  relevant  to  achieve  an  objective.  It  is  highly  unlikely  that  a 
central  planner  can  always  know  where  to  find,  or  how  to  look  for,  all  the 
necessary  bits  of  dispersed  information  known  in  the  economic  system 
relevant  to  a  problem  at  hand.  This  is  most  problematic  since  it  makes  it 
impossible  for  the  central  planner  to  be  fully  cognizant  of  the  nature  of,  or 
of  the  amount  of  gaps  in,  his  own  knowledge.  The  tragedy  of  central 
planning  toward  industrial  policy  is  that  even  the  best-intentioned  central 
planner  is  unaware  of  the  knowledge  problem,  which  is  the  ignorance  of 
his  own  ignorance.82 


81  Ashby,  W.  R.,  An  Introduction  to  Cybernetics,  London:  Chapman  &  Hall,  1960. 

82  Kirzner,  I.  M.,  The  Meaning  of  Market  Process:  Essays  in  the  Development  of  Modern  Austrian 
Economics,  London:  Routledge,  (1992)  and  Cleveland,  Paul  A.  and  Price,  Jared  R.,  The  Independent 
Review,  A  Journal  of  Political  Economy,  The  Failure  of  FAA  Regulation,  Vol.  8,  No.  1 ,  Summer  2003. 
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Similarly,  when  Rand  authors  wrote  about  DoD  decision  making  pertaining  to 
training,  equipping,  manning,  and  operating  the  force,  they  suggested  that  decisions 
should  be  based  upon  senior  leadership’s  desired  outcomes.  They  also  suggest  that 
leaders  consider  hedging  with  more  wagers  versus  single  large  bets  -  meaning  use  of 
more  brains  versus  one.  They  acknowledge  that  with  a  decentralized  management 
style  comes  dilution  of  responsibility  and  accountability,  unless  vigilance  of  execution  is 
maintained.  But  they  agree  with  other  theorists  that  centralized  decision  making  was 
consistent  with  the  Cold  War,  and  a  style  well-suited  to  the  1960s,  but  can  be  stifling 
and  can  restrict  innovation.83 

Pinchot’s  Intelligent  Organization  does  not  call  for  decentralization  to  undermine 
bureaucracy,  but  to  improve  it.  He  advocates  decentralization  with  horizontal 
interconnection  (a  network  organization)  between  business  units,  to  lessen  the  reliance 
upon  going  up  the  chain  of  command  and  down  again  for  communication  flow  and 
decision.  Rather  than  total  autonomy  for  PMs,  he  supports  self-management,  from 
trust,  with  responsibility  and  accountability.84  This  thinking  seems  particularly 
appropriate  to  a  professionalized  bureaucracy  such  as  the  DoD  acquisition  workforce, 
with  disciplined  standards  of  training,  education,  and  experience  steadily  progressing 
since  implementation  of  the  Defense  Acquisition  Workforce  Improvement  Act  (DAWIA) 
in  the  early  1990s. 

Ashby’s  Law  of  Requisite  Variety,  also  mentioned  earlier,  basically  asserts  that 
PMs  must  be  able  to  see,  understand,  and  act  with  variety  upon  their  environment  to 
survive  (my  application).  Morgan  cautions  that  senior  leaders  must  communicate 
strategy,  resource  flows,  and  timelines,  and  create  a  broad  structure  of  accountability.  If 
instead  he  is  over  controlling,  he  will  negate  any  variety  or  innovative  potential  a 


83  Johnson,  Stuart,  Libicki,  Martin  C.  and  Treverton,  Gregory  F.,  New  Challenges  New  Tools  for  Defense 
Decisionmaking,  Rand  2003. 

84  Pinchot,  Gifford  and  Elizabeth,  The  End  of  Bureaucracy  and  the  Rise  of  the  Intelligent  Organization, 
Berrett-Koehler  Publishers,  San  Francisco,  1993. 
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subordinate  unit  may  possess  -  having  to  focus  on  internal  rules  and  controls  vice 
dealing  with  the  local  challenges  being  faced.85 


85  Adapted  from  Morgan,  Gareth,  1997,  Images  of  Organization,  Sage  Publications. 
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Conclusions 


Great  strides  have  been  made  in  acquisition  of  defense  systems  over  the  past 
two  decades,  the  best  proof  of  which  might  be  from  the  performance  of  these  systems 
in  the  Persian  Gulf  War,  the  Kosovo  campaign,  Operation  Iraqi  Freedom,  and  other 
operations.  Still,  there  are  always  improvements  to  be  made  via  revisions  in  policy  and 
the  implementation  thereof.  Likewise,  there  is  a  need  on  the  part  of  implementers  to 
consider  not  only  what  the  current  policy  states,  but  what  the  secondary  and  tertiary 
effects  of  changes  might  be. 

Acquisition  models  reflect  explicit  and  even  implicit  aspects  of  acquisition  policy. 
The  author’s  research  has  not  sought  to  thoroughly  analyze  all  acquisition  policy  in  the 
past  sixteen  years,  but  to  provide  something  of  a  brief  chronicle  of  what  has  transpired 
within  the  acquisition  framework,  and  to  suggest  implications  of  the  most  recent  models 
with  regard  to  organizational  theory.  Also  presented  was  some  perspective  from 
models  phasing  the  activities  of  large  and  complex  projects  in  non-DoD  business  areas. 

As  can  be  seen  in  these  models,  changes  to  the  DoD  acquisition  system  have 
been  evolutionary,  with  an  accelerated  rate  of  change  in  the  last  three  years.  So  too, 
has  the  DoD’s  external  environment  rapidly  changed  in  these  first  years  of  the  21st 
Century,  with  more  emphasis  on  combating  global  terrorism  and  homeland  security. 

This  amount  of  change  in  the  environment  and  turbulence  in  the  policy  can  easily  lend 
to  confusion  in  the  field.  Moreover,  serious  consideration  must  be  given  to  DoD’s 
internal  organizational  control  strategy  apposite  to  a  new  age  in  acquisition. 

It  is  evident  that  the  debate  about  centralized  control  and  number  of  OSD-level 
reviews  has  been  taking  place  for  a  long  time.  The  current  model  increases  the  number 
and  levels  of  reviews,  and  their  placement  with  regard  to  program  events  indicate  that 
we  are  moving  toward  an  even  more  centralized  approach  to  control  of  acquisition 
programs. 
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This  is  in  contrast  to  the  stated  policy  and  what  has  been  publicized  about  it: 


The  [new]  policies  achieve  Wolfowitz's  and  Under  Secretary  of  Defense 
for  Acquisition,  Technology  and  Logistics  Edward  C.  “Pete”  Aldridge's 
objectives  by  giving  acquisition  decision  makers  much  greater  authority  to 
tailor  program  strategies  to  fit  the  needs  of  their  program.  Greater 
emphasis  is  now  placed  on  evolutionary  acquisition  as  the  preferred 
strategy  for  rapidly  acquiring  advanced  warfighting  capability.  Program 
managers  are  now  given  the  flexibility  to  be  creative  and  efficient  in  the 
way  they  apply  policy  to  their  programs.  The  policies  are  designed  to 
release  the  power  of  innovation  in  every  member  of  the  acquisition, 
technology  and  logistics  workforce.86 

But  what  is  perhaps  even  more  significant  than  this  observation  is  that  moving 
toward  greater  centralization  of  control  at  the  higher  levels  may  be  a  cause  for  serious 
concern,  given  predominant  management  theory  cited  herein.  The  mainstream  of 
thought  indicates  that  more  efficiency  and  effectiveness  might  be  gained  from  a  different 
approach  to  an  external  environment  of  instability  and  uncertainty,  whether  from  unclear 
threats  and  uncertain  scenarios,  or  from  complexities  of  technology  and  systems 
acquisition. 

Centralization  of  control  is  a  management  issue  to  be  dealt  with  -  the  challenge 
to  avoid  anarchy,  with  no  guidelines  or  parameters,  as  well  as  excessive  control.  Might 
programs  actually  be  lengthened  by  more  cumbersome  reviews?  Whether  fourteen 
reviews  in  eleven  years  are  too  many  is  a  matter  of  conjecture  and  more  debate. 
However,  it  is  obvious  that  there  are  today  more  reviews  than  ever  before,  and  these  do 
have  a  requisite  cost  associated  with  their  execution.  We  will  likely  continue  the 
struggle  to  find  the  appropriate  balance  between  centralized  functions  at  OSD  and 
autonomy  for  the  management  of  programs  in  both  explicit  or  implicit  management 
policies  and  frameworks. 

Likewise,  the  implications  of  delayed  program  initiation  and  shift  of  Initial 
Operational  Test  and  Evaluation  until  after  the  start  of  production  have  yet  to  be 


86  United  States  Department  of  Defense,  News  Release  No.  327-03, 
http://www.defenselink.mil/news/releases.html,  May  14,  2003. 
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realized.  A  delay  of  advanced  development  almost  certainly  means  more  time  to  be 
spent  on  the  earlier  development  processes.  And  loss  of  concurrency  via  the 
sequencing  of  LRIP  and  IOT&E  similarly  threatens  to  lengthen  at  least  some  programs 
that  could  have  performed  these  activities  simultaneously. 

An  obvious  area  for  further  research  is  on  the  subject  of  actual  costs  associated 
with  senior  level  decision  reviews.  However,  investigational  opportunities  might  also 
include  several  questions  pertaining  to  the  application  of  evolutionary  acquisition  and  its 
potential  resultant  impacts  on  Initial  Operational  Test  and  Evaluation,  configuration 
management,  “lot,  model,  &  type  diversity,”  and  associated  supportability  concerns. 
Lastly,  Pinchot’s  “horizontal  interconnections”  among  business  units  may  hold  the  key  to 
ultimate  effectiveness  and  efficiency  within  a  large  professional  bureaucracy  such  as 
the  DoD.  A  study  of  how  the  DoD  might  exploit  its  current  capacity  via  increased 
horizontal  communication  might  provide  insight  toward  attaining  the  decentralized 
empowerment  it  advocates. 
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